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

PUBLIC
2022-10-14

Payment Engine (FS-PE)

THE BEST RUN

Content

1 Payment Engine (FS-PE). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

2 What’s New in SAP Payment Engine 9.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1 Changes and New Features in SAP Payment Engine 9.0 SP12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Changes and New Features in SAP Payment Engine 9.0 SP11. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3 Changes and New Features in SAP Payment Engine 9.0 SP10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.4 Changes and New Features in SAP Payment Engine 9.0 SP09. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.5 Changes and New Features in SAP Payment Engine 9.0 SP08. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.6 Changes and New Features in SAP Payment Engine 9.0 SP07. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.7 Changes and New Features in SAP Payment Engine 9.0 SP06. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
2.8 Changes and New Features in SAP Payment Engine 9.0 SP04. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
2.9 Changes and New Features in SAP Payment Engine 9.0 SP03. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
2.10 Changes and New Features in SAP Payment Engine 9.0 SP02. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
2.11 Changes and New Features in SAP Payment Engine 9.0 SP01. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

3 End-to-End Payment Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .98

4 Basic Cross-Border STP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

4.1 Cross-Border Payment Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

5 Payment Processes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .106

5.1 Request for Cancellation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Active Request for Cancellation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Passive Request for Cancellation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
5.2 Recall of SEPA Credit Transfers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Active Recall of SEPA Credit Transfers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114
Passive Recall of SEPA Credit Transfers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118
5.3 Cash Pooling with Request for Transfer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
5.4 Foreign Exchange (Overview). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Foreign Exchange Rates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
5.5 Batch Booking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
5.6 Card Transaction Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Authorization Request Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Financial Request Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127
Authorization Reversal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

6 Clearing Area. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

7 Payment Order. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Payment Engine (FS-PE)

2 PUBLIC Content
7.1 Release Object ORDER (Payment Order). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

8 Payment Item. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

8.1 Release Object POITEM (Payment Item). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

9 Recall. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
9.1 Recall Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
9.2 Recall Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .147
9.3 Release Object RECALL (Recall). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

10 Request Agent. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

11 Connection of Internal and External Systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

11.1 Enterprise Services for Payment Engine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Application Management Framework. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Payment Transaction Order In/Event Out. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Payment Engine Connector. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
11.2 Connection to an Account Management System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
11.3 FI Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
11.4 CML Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
11.5 Connection to an Embargo System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
11.6 Connection to a Liquidity Management System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171

12 Referential Data Interface (FS-PE-RDI). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

12.1 Routing Directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Upload of Referential Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
12.2 Standard Settlement Instructions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Upload of Referential Data (Standard Settlement Instructions). . . . . . . . . . . . . . . . . . . . . . . . . 178
12.3 Bank Master Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Upload of Referential Data (Bank Master Data). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Business Partner Generation (Offline). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
12.4 Account Substitution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

13 Master Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

13.1 Rule Set. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Determining Business Objects with Rule Sets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
13.2 Charges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Editing Charge Conditions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .199
Differentiation Categories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .200
13.3 Bank File Clearing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Manage Bank File Clearing Accounts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
13.4 Routing Control (FS-PE-RP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Route. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Clearing Agreement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

Payment Engine (FS-PE)

Content PUBLIC 3
 Customer Agreement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Value Date Agreement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
13.5 Service Level Agreement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Managing Service Level Agreements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Release Object SLA (Service Level Agreement). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Status and Release Status of Master Data Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
13.6 Exception Control (FS-PE-EH). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Response Category. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Response Type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Correction Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
Exception Control Rule Set. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Foreign Exchange (FX). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Processing of Active Returns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .285
Full Rejection of Payment Orders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
Partial Rejection of Payment Orders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288

14 File Handler (FS-PE-FH). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289

14.1 Input Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
Import File (Expert). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
14.2 Output Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
14.3 File Handler Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Display File Handler Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .298
14.4 XML Converter Framework. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
ISO 8583 Converter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
SWIFT MT Converter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
SWIFT MX/T2 Converter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
14.5 Financial Services Network Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
14.6 Eurogiro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .305
14.7 Notification of Payment Order Processing Status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .306

15 Payment Processing (FS-PE-POP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309

15.1 Enrichment and Validation (FS-PE-EV). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .311
Check Processing Date. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Enrichment and Validation Check. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .313
Enrichment and Validation Check Set. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Embargo Check. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Enrichment and Validation for Outgoing Payment Orders. . . . . . . . . . . . . . . . . . . . . . . . . . . . .334
15.2 Routing Control Overview (FS-PE-RP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336

16 Clearing Processing (FS-PE-CP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337

16.1 Queue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Setting Up Queues and Collectors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342

Payment Engine (FS-PE)

4 PUBLIC Content
 Managing Queues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
16.2 Collector. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
Setting Up Queues and Collectors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
Managing Customer Collectors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
Managing Clearing Collectors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
16.3 Direct Clearing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
16.4 Assign Payment Items to Collector/Queue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
16.5 Close Collector/Queue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .361
16.6 Final Processing (Collectors/Queues). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
16.7 Account Management Proxy (FS-PE-AMP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
Posting Simulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .366
Posting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
Reservation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .369
Deletion of Reservation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .370
16.8 Alternative Clearing Scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371

17 User Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372

17.1 Payment Order. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
Edit Payment Orders (Expert). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
Create Payment (SAP Fiori). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
Create Payment Order (SAPUI5). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Manage Payments (SAP Fiori). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .385
Manage Waiting Payments (SAP Fiori). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
Display Payment Order (SAPUI5). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
17.2 Exception Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
Repair Payments (SAP Fiori). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
Exception Handling (SAPUI5). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Manage Correction Rules (SAP Fiori). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .390
17.3 Foreign Currency Trade Reporting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
17.4 Manage Payment Blocks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
17.5 Investigate Non-Financial Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
17.6 Management Cockpit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
17.7 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
Setting up Additional Search Criteria for Orders and Items. . . . . . . . . . . . . . . . . . . . . . . . . . . .395

18 Periodic Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401

18.1 End-of-Day Processing (FS-PE-EOD). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
Process Flow of End-of-Day Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
Accrual. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .405
Reconciliation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
18.2 Correspondence (FS-PE-COR). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
Start Correspondence Printing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .411

Payment Engine (FS-PE)

Content PUBLIC 5
 Display Correspondence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414

19 Logs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
19.1 Performance Analysis in the Performance Cockpit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417

20 Release Workflow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419

21 Archiving (FS-PE-ARC). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420

21.1 Maintaining Customizing Settings in Archiving Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .421
21.2 Archiving Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
ILM Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
Archive Development Kit (ADK). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .424
21.3 Archiving Payment Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
Archiving Payment Orders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
Archiving Recalls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
Archiving Request Agents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
Archiving Collector Categories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
Archiving Service Level Agreements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Archiving Object Lists. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
Archiving Bank File Clearing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
Archiving Value Date Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .435
Archiving Routes and Clearing Agreement Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
Deleting Payment Items. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
Displaying Payment Orders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
21.4 Archiving Logs and Documents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
Archiving Application Logs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
Archiving Change Documents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439

22 Information System (FS-PE-IS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440

23 DataSources in SAP Payment Engine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442

23.1 Master Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
Payment Order Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .442
Service Level Agreement Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
23.2 Flow Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .444
Object List Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .444
Payment Item Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
Payment Order Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
Payment Item Aggregated Data Extractor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
Payment Item Detailed Data Extractor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
Payment Order Aggregated Data Extractor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .453
Payment Order Detailed Data Extractor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
Reconciliation Hub: Payment Item Aggregated Data Extractor. . . . . . . . . . . . . . . . . . . . . . . . . 456

Payment Engine (FS-PE)

6 PUBLIC Content
 Reconciliation Hub: Payment Item Detailed Data Extractor. . . . . . . . . . . . . . . . . . . . . . . . . . . 458
Reconciliation Hub: Payment Order Aggregated Data Extractor. . . . . . . . . . . . . . . . . . . . . . . . 459
Reconciliation Hub: Payment Order Detailed Data Extractor. . . . . . . . . . . . . . . . . . . . . . . . . . . 461
23.3 Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
Format Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
PE Channel Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
Clearing Agreement Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .465
Clearing Area Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
Customer Agreement Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
Object List Type Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
Payment Item Category Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
Payment Order Category Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470
Payment Order Type Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
SLA Type Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
Service Level Agreement Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
Route Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474
Segment Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
Transaction Type Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476

Payment Engine (FS-PE)

Content PUBLIC 7
1 Payment Engine (FS-PE)

Use

Payment Engine (FS-PE) is a single-payment operations platform that can connect to multiple internal and
external payment channels. You use this component to verify, sort, and clear payment transactions. Its
transparent, flexible, and automated workflow can be controlled by expert users.

Payment Engine provides high straight-through processing rates, batch processing, and real-time processing,
as well as 24x7 reporting. It handles low-value, non-time-critical payments as well as high-value, time-critical
payments and also allows financial institutions to offer value-added real-time services with no interruption
from end-of-day processes.

Implementation Considerations

Payment Engine supports business models that enable financial institutions and service providers to offer
payment processing to in-house entities as well as to external financial institutions, for example, by
establishing a shared service center. In the effort towards standardization or during mergers and acquisitions,
Payment Engine can be a viable solution for consolidating legacy systems and can provide compliance
with future clearing systems, for instance, in preparation for the Single Euro Payments Area (SEPA). In the
context of international payments, Payment Engine also supports conversion and processing of SWIFT MT103+
messages (Single Customer Credit Transfer), for which it provides full straight-through processing (STP). For
more information, see Cross-Border Payment Processing [page 103].

Thanks to its parallel-processing capability and its scalability, Payment Engine can handle the high volumes
of payments typical of large financial institutions and IT service centers, while allowing institutions with lower
volumes to achieve a low total cost of ownership.

Integration

Payment Engine is a standalone product with the means of connecting banking services over the SAP
NetWeaver platform. You can connect account-management systems through a proxy infrastructure and
other external tools and applications, such as embargo, anti-money-laundering, or reporting systems, by
implementing Business Add-Ins (BAdIs), the standard technology for customer extensions. You can archive
payment transactions and other relevant data using the Archiving Engine.

For more information, see Account Management Proxy (FS-PE-AMP) [page 364], Connection of External
Systems [page 153], and Archiving (FS-PE-ARC) [page 420].

The figure below shows a basic landscape example of Payment Engine and the flow of payment information.

Payment Engine (FS-PE)

8 PUBLIC Payment Engine (FS-PE)
 Payment Engine Overview

Features

Processing Functions

Payment Engine processes payments through a workflow using these functions:

• Input channels
Payment transaction data can be delivered via various channels in various formats on various mediums.
These input channels deliver payment orders to Payment Engine in both batch mode (files) from feeder
systems and online mode (messages) over the payment order interface.
For more information, see Input Manager [page 291].
• Upload of referential data
Payment Engine supports the upload, validation, and management of referential data. The data is stored in
a generic data structure for use during routing, validation, and clearing.
For more information, see Referential Data Interface (FS-PE-RDI) [page 172].
• Format conversion
Payment Engine supports the implementation of format-specific converters for the validation and
conversion of payment information. Inbound converters read incoming payment data and convert the data
needed for processing to the internal metaformat. Other information contained in the uploaded data is
stored separately for retrieval after the payment transactions have been processed. Outbound converters
convert processed payment data to external payment data formats, for example, for export in an outgoing
file.

Payment Engine (FS-PE)

Payment Engine (FS-PE) PUBLIC 9
 For more information, see File Handler (FS-PE-FH) [page 289] and File Handler Database [page 297].
• Enrichment and validation
Based on checks for accuracy, consistency, and errors, Payment Engine validates and enriches payment
orders and payment items with defined information. An internal repair function can add or correct data
automatically, or you can correct errors manually. Other errors can be passed to an exception-handling
function. Data enrichment is also based on standard settlement instructions (SSI) to support routing of
international payments.
For more information, see Payment Processing (FS-PE-POP) [page 309], Enrichment and Validation [page
311], and Standard Settlement Instructions (SSI) [page 176].
• Routing control
Payment Engine handles internal and external payments based on defined clearing scenarios. Flexible
rules enable evaluation and route processing at payment-item level for internal payments and those
to be transferred to other financial institutions or connected account-management systems. Payment
Engine supports different types of master data, such as value date agreements, routes, and clearing
agreements. It can also calculate and validate payment transaction charges that are later posted to an
account management system.
For more information, see Routing Control (FS-PE-RP) [page 205] and Charges [page 192].
• Clearing and settlement
Payment Engine supports different clearing scenarios: direct clearing for nostro or vostro accounts,
settlement through a clearing institute, and clearing with a separate cover provision. It distributes payment
data to internal account-management systems or to outgoing clearing channels. Moreover, the system can
park individual payment items in queues for later release or can bundle them in collectors for collective
posting to internal accounts or forwarding in an outgoing payment order.
For more information, see Clearing Processing (FS-PE-CP) [page 337].
• Forwarding of payment orders
Payment Engine converts the processed data into the target format and transfers the processed and
enriched payment data to the forwarding systems.
For more information, see Output Manager [page 295].

Monitoring and Control Functions

Payment Engine provides the following functions to monitor and control the payment processing workflow:

• Payment order management

Payment Engine allows you to view all payment information during all processing phases and to
manage payment orders and payment items manually. You can, for example, prioritize urgent payment
transactions, recall payment orders, and postprocess payment data.
For more information, see Edit Payment Orders (Expert) [page 373] and Recall Management [page 144].
• Exception handling
Payment Engine provides semi-automated exception handling. If exceptions prevent further processing of a
payment transaction, the system triggers responses based on defined rules.
For more information, see Exception Control (FS-PE-EH) [page 265].
• Other functions
Payment Engine can run periodic tasks, such as end-of-day processes and correspondence. You can view
logged events, run reports, and evaluate business data. Payment Engine uses the user-management,
authorization, and authentication mechanisms provided by SAP NetWeaver.
For more information, see Periodic Processing [page 401], Logs [page 416], and Information System [page
440].

Payment Engine (FS-PE)

10 PUBLIC Payment Engine (FS-PE)
2 What’s New in SAP Payment Engine 9.0

This section provides an overview of new, changed, and deleted functions in SAP Payment Engine.

Payment Engine (FS-PE)

What’s New in SAP Payment Engine 9.0 PUBLIC 11
2.1 Changes and New Features in SAP Payment Engine 9.0
SP12

This table provides an overview of changes and new features that have been introduced in SAP Payment Engine
9.0 SP12.

Type
of
Chang
Function e Description More Information

Legal changes ac- New New XSD schemas are available according to the changes made SAP Note 3321265
cording to SEPA
to the SEPA Rulebook 2023, which is valid from 19th November
rulebook 2023 SAP Note 3312225
2023. The implemented changes are compatible with the follow-
ing rulebooks: SAP Note 3313081
• DK version 3.7 of the appendix 3 of the DFÜ-agreement
SAP Note 3312227
• SEPA SCT Rulebook 2023
SAP Note 3314582
• SEPA SDD Rulebook 2023
• SEPA SCT Instant Rulebook 2023 SAP Note 3324746

The new SEPA Rulebook 2023 converters perform the mapping SAP Note 3312228
based on the internal ISO 20022 XML representation. This has
the advantage that mapping inside of the payment remittance SAP Note 3312231

can be skipped, for example.

The following message IDs were added for the EBA converters
(credit transfer):

• /EBA_CT_R23_CAMT.027.001.07 (IB Claim Non-Receipt

(SCT) - EBA Rulebook 2023)
• /EBA_CT_R23_CAMT.029.001.09 (IB Resolution Of Investi-
gation (SCT) - EBA Rulebook 2023)
• /EBA_CT_R23_CAMT.056.001.08 (IB Payment Cancellation
Request (SCT Recall) - EBA Rulebook 2023)
• /EBA_CT_R23_CAMT.087.001.06 (IB Request to Modify
Payment (SCT) - EBA Rulebook 2023)
• /EBA_CT_R23_PACS.004.001.09 (IB Payment Return
(SCT) - EBA Rulebook 2023)
• /EBA_CT_R23_PACS.008.001.08 (IB Credit Transfer (SCT)
- EBA Rulebook 2023)
• /EBA_CT_R23_PACS.028.001.03 (IB Payment Status Re-
quest (SCT) - EBA Rulebook 2023)
• /EBA_CT_R23_PACS.002.001.10S2 (IB Payment Status
Report (SCT) - EBA Rulebook 2023)
• /EBA_CT_R23_$SCTSCFBLKCREDTRF (CVF Bulk (SCT) -
Credit Validation File - EBA Rulebook 2023)

Payment Engine (FS-PE)

12 PUBLIC What’s New in SAP Payment Engine 9.0
 Type
of
Chang
Function e Description More Information

• /EBA_CT_R23_$SCTOQFBLKCREDTRF (OQF Bulk (SCT) -

Output Inquiry File - EBA Rulebook 2023)
•
• /EBA_CT_R23_$SCTIQFBLKCREDTRF (IQF Bulk (SCT) - In-
put Inquiry File - EBA Rulebook 2023)
• /EBA_CT_R23_$SCTCVFBLKCREDTRF (CVF Bulk (SCT)
- Credit Validation File - EBA Rulebook 2023)/
EBA_CT_R23_$SCTICFBLKCREDTRF (ICF Bulk (SCT) - In-
put Credit File - EBA Rulebook 2023)
• /EBA_CT_R23_$SCTPCFBLKCREDTRF (PCF Bulk (SCT) -
Payment Cancellation File - EBA Rulebook 2023)
• /EBA_CT_R23_$SCTQVFBLKCREDTRF (QVF Bulk (SCT) -
Inquiry Validation File - EBA Rulebook 2023)

The following message IDs were added for the EBA converters
(direct debit):

• /EBA_DD_R23_CAMT.056.001.08 (IB Payment Cancella-

tion Request (SDD) - EBA Rulebook 2023)
• /EBA_CT_R23_$SCTICFBLKCREDTRF (ICF Bulk (SCT) -
Input Credit/EBA_DD_R23_PACS.002.001.10 (IB Payment
Status Report (SDD Rejects) - EBA Rulebook 2023)
• /EBA_DD_R23_PACS.002.001.10S2 (IB Payment Status
Report (SDD) - EBA Rulebook 2023)
• /EBA_DD_R23_PACS.003.001.08 (IB Direct Debit (SDD) -
EBA Rulebook 2023)
• /EBA_DD_R23_PACS.004.001.09 (IB Payment Return
(SDD) - EBA Rulebook 2023)
• /EBA_DD_R23_PACS.007.001.09 (IB Payment Reversal
(SDD) - EBA Rulebook 2023)
• /EBA_DD_R23_$MPEDDDNFBLKDIRDEB (DNF Bulk (SDD)
- Debit Notification File - EBA Rulebook 2023)
• /EBA_DD_R23_$MPEDDDVFBLKDIRDEB (DVF Bulk (SDD)
- Debit Validation File - EBA Rulebook 2023)
• /EBA_DD_R23_$MPEDDIDFBLKDIRDEB (IDF Bulk (SDD) -
Input Debit File - EBA Rulebook 2023)
• /EBA_DD_R23_$MPEDDRSFBLKDIRDEB (RSF Bulk (SDD)
- Results of Settlement File - EBA Rulebook 2023)

The following message IDs were added for the EBA converters
(instant payments):

• /EBA_IP_R23_CAMT.029.001.09 (IB Resolution of Investi-

gation (SCT Inst) - EBA SCT Instant Rulebook 2023)

Payment Engine (FS-PE)

What’s New in SAP Payment Engine 9.0 PUBLIC 13
 Type
of
Chang
Function e Description More Information

• /EBA_IP_R23_CAMT.056.001.08 (IB Request for Cancella-

tion (SCT Inst) - EBA SCT Instant Rulebook 2023)
• /EBA_IP_R23_PACS.002.001.10 (IB Payment Status Report
(SCT Inst) - EBA SCT Instant Rulebook 2023)
• /EBA_IP_R23_PACS.004.001.09 (IB Payment Cancellation
Request (SCT Inst) - EBA Rulebook 2023)
• /EBA_IP_R23_PACS.008.001.08 (IB Credit Transfer (SCT
Inst) - EBA SCT Instant Rulebook 2023)
• /EBA_IP_R23_PACS.028.001.03 (IB Payment Status Re-
quest - EBA SCT Instant Rulebook 2023)

The following message IDs were added for the DK converters

(credit transfer and direct debit):

• /DK_CT_R23_PAIN.001.001.09 (Customer Credit Transfer

Initiation DK 3.7 - 2023)
• /DK_IP_R23_PAIN.001.001.09 (Customer Credit Transfer
Initiation for IP DK 3.7 - 2023)
• /DK_DD_R23_PAIN.008.001.08 (Customer Direct Debit DK
3.7 - 2023)
• /DK_R23_CAMT.054.001.08 (Bank to Customer Debit
Credit Notification DK 3.7 - 2023)
• /DK_IP_R23_CAMT.054.001.08 (Bank to Customer Credit
Notification for SCT Inst DK 3.7 - 2023)
• /DK_R23_PAIN.002.001.10 (Customer Payment Status Re-
port DK 3.7 - 2023)
• /DK_R23_PAIN.007.001.09 (Customer Payment Reversal
DK 3.7 - 2023)
• /DK_R23_CONTAINER.NNN.001.04 (Container DK 3.7 -
2023)

The following new entry is available for the SEPA Rulebook

changes in Customizing for Payment Engine under File

Handler XML Converter Development Maintain Payment

Regulation Release Validity .

• 19th November 2023 for SEPA2023 (new entry)

 Note
The migration to SEPA Rulebook 2023 was postponed
by EBA/EPC from 19th November 2023 to 17th March
2024. This change affects all SEPA 2023 credit transfer,

Payment Engine (FS-PE)

14 PUBLIC What’s New in SAP Payment Engine 9.0
 Type
of
Chang
Function e Description More Information

direct debit and instant payment converters (EBA, DK,

BuBa). Therefore, you must change the entry in Customiz-

ing for Payment Centralization under File Handler XML

Converter Development Maintain Payment Regulation

Release Validity as follows:

• 17th March 2024 for SEPA2023

Payment Engine (FS-PE)

What’s New in SAP Payment Engine 9.0 PUBLIC 15
 Type
of
Chang
Function e Description More Information

Legal changes ac- New New XSD schemas are available according to the changes made SAP Note 3354372
cording to SEPA to the SEPA Rulebook 2023, which is valid from 19th November
Rulebook 2023 2023. The implemented changes are compatible with the follow-
(Bundesbank con- ing rulebooks:
verters and XSDs)
• SEPA Credit Transfer Scheme Rulebook, 2023 Version 1.0
SEPA Core Direct Debit Scheme Rulebook, 2023 Version 1.0
SEPA Business to Business Direct Debit Scheme Rulebook,
2023 Version 1.0

The following message IDs were added for the Bundesbank con-
verters (credit transfer):

• /BUB_CT_R23_$BBKCVFBLKCDTTRF
• /BUB_CT_R23_$BBKICFBLKCDTTRF
• /BUB_CT_R23_$BBKIQFBLKCDTTRF
• /BUB_CT_R23_$BBKOQFBLKCDTTRF
• /BUB_CT_R23_$BBKQVFBLKCDTTRF
• /BUB_CT_R23_$BBKSCFBLKCDTTRF
• /BUB_CT_R23_CAMT.027.001.07
• /BUB_CT_R23_CAMT.029.001.09
• /BUB_CT_R23_CAMT.056.001.08SCT
• /BUB_CT_R23_CAMT.087.001.06
• /BUB_CT_R23_PACS.002.001.10SCL
• /BUB_CT_R23_PACS.004.001.09SCT
• /BUB_CT_R23_PACS.008.001.08
• /BUB_CT_R23_PACS.028.001.03

The following message IDs were added for the Bundesbank con-
verters (direct debit):

• /BUB_DD_R23_$BBKDNFBLKDIRDEB
• /BUB_DD_R23_$BBKDVFBLKDIRDEB
• /BUB_DD_R23_$BBKIDFBLKDIRDEB
• /BUB_DD_R23_$BBKRSFBLKDIRDEB
• /BUB_DD_R23_$BBKSDFBLKDIRDEB
• /BUB_DD_R23_CAMT.056.001.08
• /BUB_DD_R23_PACS.002.001.10SCL
• /BUB_DD_R23_PACS.002.001.10SDD
• /BUB_DD_R23_PACS.003.001.08
• /BUB_DD_R23_PACS.004.001.09SDD
• /BUB_DD_R23_PACS.007.001.09

Payment Engine (FS-PE)

16 PUBLIC What’s New in SAP Payment Engine 9.0
 Type
of
Chang
Function e Description More Information

Direct debit order Bugfix Up-to-date mapping is now available for direct debit orders,
SAP Note 3365617
mapping by syn- which is required for payment order processing using the
chronous service PaymentTransactionProcessingManagePaymentTransactionOrde SAP Note 3365616
rIn service.

Generating status New It is now possible for the originator bank to send an inquiry SAP Note 3363809
request (pacs.028)
message (pacs.028) to the beneficiary bank to inquire about
based on an out- SAP Note 3365284
the actual status of the initial payment cancellation request
bound camt.056
(camt.056).

Data storage card New The data storage for card processing was optimized. The card- SAP Note 3267273
processing
related data is stored in database table /PE1/DB_CARD_DET
SAP Note 3271294
instead of creating single payment remittances. The storage of
card-related data in a single row reduces the usage of disk space SAP Note 3266897
significantly. To avoid side effects in the end-to-end processes,
the following changes were additionally implemented: SAP Note 3317863

• For investigation purposes, the card-related data can be

SAP Note 3317965
shown in PO Expert with an additional screen
• For providing data to Deposit Management, functional types
can be defined to create payment notes
• The Business Add-In (BAdI) for customer-specific mapping
allows also to map and update card-related data

The following bugs were fixed during the implementation::

• The response payloads for authorization and financial mes-

sages can be stored in the File Handler database
• The request payloads for authorization and financial mes-
sages were stored multiple time before. Now the payload is
stored once for the payment order.

Validations of New The following messages are validated against standard

SAP Note 3332879
ISO20022 and ISO20022 and CBPR Plus rules.
CBPR Plus rules
• pacs.008
• pacs.009
• pacs.004

The technical validation based on XSD was already in place,

but the validation against formal rules (for example, structured
or unstructured payment remittance) was not. The validation
against standard ISO20022 and CBPR Plus rules was intro-
duced. The rules will be extended and also implemented for
other payment schemes (for example, EBA) in the future.

Payment Engine (FS-PE)

What’s New in SAP Payment Engine 9.0 PUBLIC 17
 Type
of
Chang
Function e Description More Information

New framework to New The class /PE1/CL_IPM_NOTIFICATION was updated to act SAP Note 3281166
process status no-
as a framework for processing incoming status notifications. As
tifications
long as the format is based on XML, you just have to configure
in a subclass how to retrieve references and status information.
The framework takes care about the following:

• Storage of the payload in File Handler database

• Matching the status update with internal objects
• Updating the forwarding status of internal objects
• Error handling

The latest implementations of ADMI.007, PACS.002 and

PAIN.002 are using this framework.

Cross-border pay- New Update of existing converters for SWIFT Release 2022
ments and report-
ing plus (CBPR+)
SR 2022

Cross-border pay- New New converters and XSDs for CBPR Plus SWIFT MX SAP Note 3366543
ments and report-
SR2023. Additionally, we provide dedicated implementations for
ing plus (CBPR+)
pacs.008STP, pacs.009ADV and pacs.009COV:
SR 2023
• /MX_R23_PACS.008.001.08STP (CBPRPlus SR23 FI To FI
Customer Credit Transfer STP)
• /MX_R23_PACS.009.001.08ADV (CBPRPlus SR23 Finan-
cial Institution Credit Transfer ADV)
• /MX_R23_PACS.009.001.08COV (CBPRPlus SR23 Finan-
cial Institution Credit Transfer COV)

The following new entry is available in Customizing for Payment

Engine under File Handler XML Converter Development

Maintain Payment Regulation Release Validity for the CBPR

Plus Standards Release 2023 changes:

• 19th November 2023 for CBPR2023 (new entry)

See Customizing for Payment Engine under File Handler

XML Converter Development Maintain Payment Regulation

Release Validity .

Payment Engine (FS-PE)

18 PUBLIC What’s New in SAP Payment Engine 9.0
 Type
of
Chang
Function e Description More Information

Reconciliation re- Chang The following changes and corrections were made to the recon- SAP Note 3258849
port e/
ciliation report:
Bugfix SAP Note 3273169
• If a difference is identified between the Payment Engine and
the Transactional Banking (TRBK) system due to missing SAP Note 3299506
items in TRBK, these items can be automatically reposted
SAP Note 3329176
to TRBK. A new flag was added to the reconciliation report.
This flag allows to repost items if the system has identified SAP Note 3361608
that these items exist in Payment Engine but not in TRBK.
SAP Note 3361558
• You can now define which objects are saved in reconciliation
database tables.
• If the reconciliation unit is not provided externally, it is de-
rived by default based on the Customizing where format,
medium and channel are used. The disadvantage of this
approach may occur for formats with envelopes containing
different formats inside (example: BIZ message containing
pacs.008). Thus, this correction provides the option to de-
fine additional rules based on payment order types.
• If a currency exchange process is executed on TRBK side,
the reconciliation report for validating posting showed dif-
ferences erroneously. Then the account currency was com-
pared with the transaction currency which led to differences
in the reporting. This is now fixed.
• Incorrect results in the ALV table display and the incorrect
structure of the AM item details were fixed.

Customizable New The function module BAPI_TRANSACTION_COMMIT, which is

SAP Note 3262644
WAIT parameter in used to commit data in Transactional Banking, can now be
RFC called in synchronous and asynchronous mode. The type of call
BAPI_TRANSACTI can be maintained in Customizing for Payment Engine under
ON_COMMIT Posting Interfaces Account Management Systems Define
Account Management Areas .

Payment Engine (FS-PE)

What’s New in SAP Payment Engine 9.0 PUBLIC 19
 Type
of
Chang
Function e Description More Information

SAPUI5 UI adapta- New The new UI Adaptation feature is now enabled for the Fiori appli- SAP Note 3238112
tion for Fiori appli-
cations.
cations SAP Note 3350045
UI adaptation is a feature of SAPUI5 flexibility that allows key
users without technical knowledge to easily make UI changes for SAP Note 3350044
all users of an app. SAP Note 3350043
To use this feature, a key-user-role needs to be assigned to the
SAP Note 3350042
corresponding user.
SAP Note 3350038
For more information, see What is SAPUI5 Flexibility?.
SAP Note 3350006

SAP Note 3316896

SAP Note 3374315

Skip mapping of New

 Note SAP Note 3271843
the payment re-
mittance This feature is currently only used in the new SEPA Rule-
book 2023 converters and the ISO8583 converters.

You can now skip payment remittance creation during import. To

do this, the Skip PR creation flag needs to be selected for the
specific converter in Customizing for Payment Centralization un-
der File Handler XML Converter Development Define
Converter Implementation for Format Converter (/PE1/
V_FH_XML). In this case, only the unstructured payment remit-
tance is mapped. The remaining entries are stored in the internal
ISO 20022 XML representation (for example, address data or
ultimate creditor).

Small online or- Bugfix Small orders that are received via online services (for example,
SAP Note 3267394
ders are now proc- Web Service) are now processed with the standard header flag
essed with stand- "online". This can avoid issues if an outgoing order is created
ard header flag in the same LUW as the incoming order (for example, if an out-
"online" going order is processed twice because it is committed to the
database earlier then it should be).

Payment Engine (FS-PE)

20 PUBLIC What’s New in SAP Payment Engine 9.0
 Type
of
Chang
Function e Description More Information

Roll-back mech- New A transaction monitoring can be now activated for the SOA SAP Note 3330838
anism for ac-
based account management proxy. By activating the transaction
count manage-
monitoring, the proxy reacts immediately in case of a roll-back
ment proxy
using the following reactions:

• Posted items canceled

• Created prenotes are deleted.

In addition, the following new feature was introduced for the rec-
onciliation report /PE1/RCN_AUTO_PS_AM: An optional param-
eter to cancel postings that were created from the payments
system but only exist in the account management system. This
feature is generic but is currently only supported from the SOA
based proxy.

Delayed ORP proc- Chang Performance improvement in delayed ORP processing to avoid
SAP Note 3338135
essing e unnecessary recipient item processing during resubmission.

Buffering settings Bugfix The buffering for table /PE1/DB_UI_LOCKS was disabled, be-
SAP Note 3275941
for table /PE1/ cause buffering type used so far ("fully buffered") led to an
DB_UI_LOCKS exception while opening an object in a Fiori application if more
than one active AS instance was used.

Duplicate check in Bugfix The submission timestamp for a payment order duplica-
SAP Note 3296196
EoD mode tion check and the date range for duplication search is
now performed bases on payment order type Customizing.
If the flag Processing Based on System Date and Time
(FLG_PROC_BASE_SYS) is set, the system date is used. If the
flag is not set, the reconciliation date is used.

Payment order in It is now possible to recalling a final payment order.

SAP Note 3307912
final status can be
recalled

Immediate proc- A new flag was added to Customizing activitiy Maintain Payment
SAP Note 3333613
essing of an active Order Types for Active Returns /PE1/V_AR_POTYPE. When you
return order set this flag, you allow the system to process an active return
order immediately.

Results of recon- Bugfix The derivation of the debit/credit indicator if account balance is
SAP Note 3336627
ciliation of state- zero has been corrected. Additionally, a fall-back mechanism to
ment balance derive the account connection in case of rejected entry items is
now available.

SWIFT MX Busi- Bugfix During the processing of an MX message, any XSD error on BAH
SAP Note 3338788
ness Application level now raises an exception on payment order level.
Header (BAH) is
not validated by
MX XSD schema

Payment Engine (FS-PE)

What’s New in SAP Payment Engine 9.0 PUBLIC 21
 Type
of
Chang
Function e Description More Information

Charge limits New / The following changes apply to charge limits:

SAP Note 3341400
Bugfix
• Charge limits are not applied for foreign currencies.
SAP Note 3347551
• For the charge limit calculation now the account currency is
used.
• Charges can be partly or fully applied.

Performance opti- Bugfix Measures were taken to optimize performance in the following
SAP Note 3352320
mization areas:

• DB selects (new indexes were created) SAP Note 3356062

• Reading non-binary items (using binary search)

Fiori APP "Manage Bugfix The Manage Bank Payments fiori app now shows all dates based
SAP Note 3363999
Bank Payments" on server time zone. The time zone of the user's local machine is
shows dates based not taken into consideration.
on the server time
zone

BAdI for prenote New The new Business Add-In (BAdI) /PE1/
SAP Note 3367414
creation BAPI BDI_RESERVATION_EXTENTION was created for the prenote
creation BAPI (BAPI_BCA_PRENOTE_CREATE). With this BAdI,
the transfer extension tables can now be processed using the
CREATE_RESERVATION method during the creation of prenotes
via AM Proxy class.

Determination of Bugfix The existing payment order size determination logic was ad-
SAP Note 3274036
payment order justed to handle the number of payment order items correctly.
size in XML con-
verter framework

Payment Engine (FS-PE)

22 PUBLIC What’s New in SAP Payment Engine 9.0
2.2 Changes and New Features in SAP Payment Engine 9.0
SP11

This table provides an overview of changes and new features that have been introduced in SAP Payment Engine
9.0, SP11.

Type
of
Chang
Function e Description More Information

Update reservation New An update reservation function in AM proxy /PE1/ SAP Note 3142726
function in AM CL_BC_ACCTPRX_SAP_DM is now enabled. This al-
proxy lows you to update existing and active prenotes
and to change the amount of the prenote.
The new E&V check /PE1/CL_PO_E_EV_CHECK_PI-
>CHECK_E_INCREMENT_RESERVATION (check ID 400) checks
if a valid reservation already exists with the same reference as
the one being processed. If it does, the existing reservation will
be cancelled and the current item will increase its amount to the
sum of the current requested amount and the old reservation
item. There should be only one reservation item for a given refer-
ence in Payment Engine.

SWIFT CBPR+ and New The following new MX CBPR+ and TARGET2 inbound converters SAP Note 3167460
TARGET2 pacs.010
are available:
converter
• /MX_PACS.010.001.03 (MX - Financial Institution Direct
Debit V03)
• /T2_PACS.010.001.03 (T2 - Financial Institution Direct
Debit V03)

Payment Engine (FS-PE)

What’s New in SAP Payment Engine 9.0 PUBLIC 23
 Type
of
Chang
Function e Description More Information

SWIFT MT re- New A new Customizing activity (view /PE1/V_SWIFT_RET) for han- SAP Note 3143187
turn/reject Cus-
dling SWIFT MT returns and rejects is now available. In this Cus-
tomizing
tomizing activity, you can map Payment Engine return reason
codes to SWIFT reason codes and details for outgoing SWIFT
MT messages. This information is mapped to SWIFT MT field
72 (Sender to Receiver Information) and is used in the following
SWIFT MT outbound messages: 103, 202, 202 COV. You can
either assign an ISO code or enter a free reason code. Addition-
ally, you can maintain the mandatory erroneous SWIFT field,
return type (RETN/REJT) and optional return/reject reason de-
scription and additional text. Furthermore, a default entry can be
maintained (without specifying a PE reason code), which will be
selected if no matching entry was found.

 Note
In the case of the returns/rejects, only the return/reject-re-
lated information is mapped to field 72. All other informa-
tion is skipped, for example /INS/ (Instructing Institution)
or other sender to receiver information.

Improvements in Chang Improvements were made in SWIFT MT messages related to the SAP Notes 3134023 ,
SWIFT MT con- e 3138840 , 3141790 ,
following:
verters 3171043
• Mapping return/reject information and marking the origi-
nal payment as returned in inbound messages (SAP Note
3134023)
• Mapping of field 50 (ordering customer) and 59 (benefi-
ciary customer) of outbound return/reject messages (SAP
Note 3138840)
• UETR mapping in case of active returns (SAP Note
3141790)
• Forwarding of address data in field 50 (ordering customer)
(SAP Note 3171043)

Payment Engine (FS-PE)

24 PUBLIC What’s New in SAP Payment Engine 9.0
 Type
of
Chang
Function e Description More Information

Exception handling New Two new exception handling methods are available to manage SAP Notes 3220665 ,
methods for exter-
external status notifications. Both methods can be used to man- 3221885 , 3224428
nal status notifica-
age external notifications (rejection) that are triggered from the
tion
forwarding status framework.

One of the methods is designed for bulk rejects, which means

that the notification affects the outgoing payment order. You
can configure it in the Customizing view /PE1/V_EH_PO_MRJ.
The other method is designed to manage transaction rejects,
which affects the recipient party item. You can configure it in the
Customizing view /PE1/V_EH_PI_MRJ.

These methods can only be used for exception handling process

68 (external status response). These methods are used as wrap-
pers that are dispatched to existing exception handling methods
based on the payment scenario and best practices.

 Example
• Case 1: An instant payment has been rejected by the
clearing institute. In this case, the recipient party item
is removed from the outgoing order, and the customer
payment initiation (inbound order) is rejected.
• Case 2: A credit transfer (batch) has been rejected by
the clearing institute. In this case, if the clearing item
was posted, the Active Return for Clearer Rejects func-
tion is triggered.

If the dispatching does not work or can be performed only parti-

ally, fallback actions take place automatically.

 Example
• After the recipient party item has been removed from
the outgoing order, the item cannot be returned. Thus,
the item is handed over for manual repair, and there is
no need to define a default response manually.
• An external notification (reject) has been received for
a payment that was already returned. The fallback in
this case is to create a technical postprocessing order
(PPO).

Payment Engine (FS-PE)

What’s New in SAP Payment Engine 9.0 PUBLIC 25
 Type
of
Chang
Function e Description More Information

The reasons for introducing these wrappers for external rejects

are based on the following aspects:

• Exception handling is flexible and modular but complex to

configure for external rejects with multiple steps.
• The existing solution for external rejects required the con-
figuration of multiple reaction type variants. This activity
was mainly required to transport the rejection reason code
from the outbound order to the inbound order.
• Exception handling for forwarded payments was not avail-
able. The wrappers also manage rejections for forwarded
payments.
• Some exception handling methods (for example, active re-
turn) are only available on item level. In case of a bulk reject,
it was necessary to ignore the error on order level to trans-
fer it to item level. When the wrapper is used, the manually
configured handover to the item level is not required.
• The wrappers are dispatched based on the payment sce-
nario, where in most cases you don't have an alternative to
react to it.

 Example
If the clearing item is posted, only an active return for
clearer rejects can be performed to correct the posting
on the clearing account. It is subsequently not neces-
sary to configure it manually.

• All existing response types in exception handling can still be

used. We recommend using the wrapper as the default re-
sponse. For specific error situations, the existing exception
handling methods can still be used.

 Example
• The bulk payment has been rejected from the
clearing institute because the cut-off time for set-
tlement has been exceeded.
In this situation, it is still worth deciding if the ex-
ception handling method for reprocessing should
be used.
For all other cases, the wrapper will correct the
postings or decline the payment initiation from the
customer.

Payment Engine (FS-PE)

26 PUBLIC What’s New in SAP Payment Engine 9.0
 Type
of
Chang
Function e Description More Information

Prerequisites:

• You can define the new exception handling methods in the

same way as other methods.
• You must ensure that internal return and rejections reasons
are assigned to the forwarding statuses. This configuration
allows existing exception handling to be used without defin-
ing a response type just to derive the internal reason code.
However, the configuration is still required, such as deriving
the transaction types for returning payments.

New TARGET2 New The new TARGET2 T2S directory can be uploaded via the ref- SAP Note 3218048
routing directory erential data uploader. The import can be started with trans-
action /PE1/UPLOAD_RD by using the parameter T2S (data
model) and BUB (data provider).

New EBA TIPS New The EBA TIPS (TARGET instant payments) directory can be up- 3108346
routing directory loaded using the referential data uploader. The import can be
started with transaction /PE1/UPLOAD_RD by using the param-
eters TIP (data model) and EBA (data provider).

Sample Customiz- New Sample Customizing for processing of CBPR+ SWIFT MX and SAP Note 2859432
ing for CBPR+ TARGET2 files and payments is now available.
SWIFT MX and
TARGET2

Payment Engine (FS-PE)

What’s New in SAP Payment Engine 9.0 PUBLIC 27
 Type
of
Chang
Function e Description More Information

Cover matching for New A new cover matching process was introduced for SWIFT MX SAP Notes 3230042 ,
CBPR+ SWIFT MX 3236850 , 3236183 ,
based on CBRPR+ requirements. The new cover matching proc-
ess does not use the request agent anymore and is managed 3235751

within enrichment and validation. The cover matching process

for SWIFT MX requires the following changes and adjustments:

• The request agent is no longer used for the matching proc-

ess. Thus, you must change the existing application man-
agement area for cover matching. Your defined application
management area needs to refer to the new application
management system COV_EV.
• The E&V check ID 000264 must be assigned to check
sets for payment orders that are used for the processing
of pacs.008 credit transfers. This E&V method validates
the settlement method as a basis step. If the settlement
method is COV, the cover status is set with 1 (Requires
cover) and an exception is triggered with error ID 000804.
You need to define in exception control that error ID
000804 is assigned to the response type for cover match-
ing.
• The E&V check ID 000361 must be assigned to check sets
for entry items that are used for the processing of camt.054
notifications. This E&V method searches the payment that
is waiting for a cover payment based on UETR (fallback in-
struction ID) and debtor agent BIC. If a match can be found,
the payment waiting for cover is updated and reprocessed
for posting automatically. This function covers CBPR+ use
case p.9.2.1 step number 5 as creditor agent.
• The E&V check ID 000441 has the same logic as 000361
but can be assigned to check sets for recipient party items.
The purpose of this check is to also support scenarios in
which the creditor agent’s correspondence bank cannot
provide a camt.054 notification. In place of a notification
(camt.054), the pacs.009 COV is forwarded to the creditor
agent as is. Ensure that the pacs.009 COV is posted to the
correct suspense account using customer-specific logic.

Payment Engine (FS-PE)

28 PUBLIC What’s New in SAP Payment Engine 9.0
 Type
of
Chang
Function e Description More Information

Improvements in Chang Improvements were made in CBPR+ SWIFT MX and TARGET2 SAP Notes 3110749 ,
SWIFT MX and e 3196941 , 3222030 ,
pacs.004 converters related to the following:
TARGET2 returns 3231230 , 3215776
• Mapping of address data of an outbound pacs.004 (SAP
Note 3110749)
• Mapping of the postal address in the return chain of
the outbound pacs.004 message (SAP Notes 3196941,
3222030, 3231230)
• Determination of the original item using UETR (SAP Note
3215776)

Improvements in Chang Improvements were made in CBPR+ SWIFT MX and TARGET2 SAP Notes 3216594 ,
SWIFT MX and e 3219544
messages related to the following:
TARGET2 convert-
ers • Handling of default item values (SAP Note 3216594)
• MX pacs.002 (payment status report): The forwarding sta-
tus is inherited from the item to the order (SAP Note
3219544)

TARGET2 business New The business application header (BAH) for TARGET2 version SAP Note 3211166
application header 2.2, which is valid since April 2022, is available.
(BAH)

Outbound conver- Chang Tags from internal ISO XML representation to target XSD format 3113275
sion of new ISO e were previously copied in a schema-compliant way, and optional
based converters tags were automatically removed during outbound conversion.
Therefore, invalid tags were not copied. However, due to this the
user does not receive any error or information message in this
case. A structural schema compliance is now used to copy the
internal ISO XML representation to the target structure. There-
fore, only valid paths will be used but individual field validation
errors can be preserved.

New EH error ID New The new error ID 007005 was introduced for errors occurring SAP Note 3120274
for collector pipe- during collector pipeline creation. Before, all errors during the
line creation errors pipeline creation were passed to exception handling (EH) with a
generic technical error. Hence, it was not possible to react to this
specific error situation.

Improvements in Chang The UI lock manager report (/PE1/R_UI_LOCK_MANAGER) was 3115811

UI lock manager e
adjusted. The following options are now available:

• Selection of the locks for objects in final state

• Selection of the locks for archived or deleted objects
• Deletion of all selected locks

Payment Engine (FS-PE)

What’s New in SAP Payment Engine 9.0 PUBLIC 29
 Type
of
Chang
Function e Description More Information

Charge bearer Chang The value SLEV/SLV is now used internally in the charge bearer SAP Note 3138758
SLEV e and the fee info field of the payment item. Until now, the default
SHAR/SHA was used internally when processing an inbound file
with this value. Both SHA and SLEV refer to the following: Both
parties bear their own charges, but SLEV is recommended for
SEPA payments.

Improvements in Chang If a payment remittance type, a payment note type, and an ob- SAP Note 3221529
PE/AM mapping e ject category are specified, the payment remittance entry will
be mapped to the payment note entry only if the maintained
object category (field OBJECT_CATEGORY from Customizing
table /PE1/T_AM_REMMAP) equals the object category of the
processed entry (for example OBJECT_CATEGORY = '06' (recipi-
ent item)). Hence, the payment remittance entry will be mapped
to the payment note only if the processed object has the same
object category ('06' (recipient item)).

Improvements in Chang A duplication check was added. If there is already a status noti- SAP Note 3212332
status notification e fication entry in /PE1/DB_FHNOTIFY that relates to the same
object and has the same item/order status, the existing entry is
updated instead of a new entry being created.

Payment order New A "strict access" check was added for payment order save/up- SAP Note 3207684
saving date. This control activates a check that verifies any write access
to the payment object to avoid data loss by obsolete payment
information from within standard coding, custom coding, or en-
hancements. After a payment order insert/update in the inter-
nal buffer, the last update counter (the last counter when the
database was updated) is saved. The same mechanism was
implemented for payment items with SAP Note 2824886 .

Enhancement of Chang The ordering party and recipient party BAPI structure was en- SAP Note 3169040
ordering party and e hanced by the account holder (ACCOUNT_HOLDER_ID) field.
recipient party This information is now mapped to the PE ordering party and
BAPI structure recipient party item and allows the sending of the business part-
ner ID with the transaction.

Improvements in Chang The Display File Handler Database transaction (/PE1/ SAP Note 3157890
Display File e FH_SHOW_DB) was enhanced by an option to display extended
Handler Database content. This allows you to see the list of objects, similar to the
Edit Payment Orders (Expert) transaction (/PE1/PO_EXPERT).

Improvements in Chang For some business processes, it is necessary to send back cus- 3145164
free message serv- e tom logs in the free message service response instead of the
ice standard Payment Engine log message if a payment was proc-
essed successfully. Now it is possible to fill the LOG structure
in the outgoing structure via the BAdI Free Message Service
Integration.

Improvements in Chang The handling of parallel processing exceptions was adjusted. If 3140560
poller processing e a parallel processing exception is raised during the incoming
payment order processing in batch mode, the poller report is
aborted.

Payment Engine (FS-PE)

30 PUBLIC What’s New in SAP Payment Engine 9.0
 Type
of
Chang
Function e Description More Information

Improvements in Chang Final payment orders with status '130' (All items of inbound 3107028
exception handling e order final) are now excluded from recall processing. Instead, a
corresponding payment item recall is triggered.

Payment Engine (FS-PE)

What’s New in SAP Payment Engine 9.0 PUBLIC 31
2.3 Changes and New Features in SAP Payment Engine 9.0
SP10

This table provides an overview of changes and new features that have been introduced in SAP Payment Engine
9.0, SP10.

Type
of
Chang
Function e Description More Information

Legal changes ac- New New XSD schemas are available according to the changes made SAP Note 3068770
cording to SEPA to the SEPA Rulebook 2021, which is valid from 21th November
SAP Note 3093027
Rulebook 2021 2021. The implemented changes are compatible with the follow-
ing rulebooks:

• DK version 3.5 of the appendix 3 of the DFÜ-agreement

• SEPA SCT Rulebook 2021
• SEPA SDD Rulebook 2021
• SEPA SCT Instant Rulebook 2021

The following message IDs were added for the EBA converters
(credit transfer):

• /EBA_CT_R21_CAMT.027.001.06 (Claim Non-Receipt

(SCT)1)
• /EBA_CT_R21_CAMT.029.001.03 (Resolution Of Investiga-
tion V03 (SCT))
• /EBA_CT_R21_CAMT.029.001.08 (Resolution Of Investiga-
tion V08 (SCT))
• /EBA_CT_R21_CAMT.056.001.01 (Interbank Payment Can-
cellation Request (SCT Recall))
• /EBA_CT_R21_CAMT.087.001.05 (Request to Modify Pay-
ment)
• /EBA_CT_R21_PACS.002.001.03S2 (Interbank Payment
Status Report (SCT))
• /EBA_CT_R21_PACS.004.001.02 (Interbank Payment Re-
turn (SCT))
• /EBA_CT_R21_PACS.008.001.02 (Interbank Credit Transfer
(SCT))
• /EBA_CT_R21_PACS.028.001.01 (Interbank Payment Sta-
tus Request (SCT))
• /EBA_CT_R21_$SCTCVFBLKCREDTRF (EBA SCT Bulk CVF
- Credit Validation File)
• /EBA_CT_R21_$SCTICFBLKCREDTRF (EBA SCT Bulk ICF -
Input Credit File)

Payment Engine (FS-PE)

32 PUBLIC What’s New in SAP Payment Engine 9.0
 Type
of
Chang
Function e Description More Information

• /EBA_CT_R21_$SCTIQFBLKCREDTRF (EBA SCT Bulk IQF -

Input Inquiry File)
• /EBA_CT_R21_$SCTOQFBLKCREDTRF (EBA SCT Bulk OQF
- Output Inquiry File)
• /EBA_CT_R21_$SCTPCFBLKCREDTRF (EBA SCT Bulk PCF
- Payment Cancellation File)
• /EBA_CT_R21_$SCTQVFBLKCREDTRF (EBA SCT Bulk QVF
- Inquiry Validation File)
• /EBA_CT_R21_$SCTSCFBLKCREDTRF (EBA SCT Bulk SCF
- Settled Credit File)

The following message IDs were added for the Bundesbank con-
verters (credit transfer):

• /BUB_CT_R21_CAMT.027.001.06 (Bundesbank SCT

camt.027.001.06)
• /BUB_CT_R21_CAMT.029.001.03 (Bundesbank SCT
camt.029.001.03 V03)
• /BUB_CT_R21_CAMT.029.001.08 (Bundesbank SCT
camt.029.001.03 V08)
• /BUB_CT_R21_CAMT.056.001.01SCT (Bundesbank SCT
camt.056.001.01SCT)
• /BUB_CT_R21_CAMT.087.001.05 (Bundesbank SCT
camt.087.001.05)
• /BUB_CT_R21_PACS.002.001.03SCL (Bundesbank SCT
pacs.002SCL)
• /BUB_CT_R21_PACS.004.001.02SCT (Bundesbank SCT
pacs.004.001.02SCT)
• /BUB_CT_R21_PACS.008.001.02 (Bundesbank SCT
pacs.008.001.02)
• /BUB_CT_R21_PACS.028.001.01 (Bundesbank SCT
pacs.028.001.01)
• /BUB_CT_R21_$BBKCVFBLKCDTTRF (Bundesbank SCT
Bulk CVF - Credit Validation File)
• /BUB_CT_R21_$BBKICFBLKCDTTRF (Bundesbank SCT
Bulk ICF - Input Credit File)
• /BUB_CT_R21_$BBKIQFBLKCDTTRF (Bundesbank SCT
Bulk IQF - Input Inquiry File)
• /BUB_CT_R21_$BBKOQFBLKCDTTRF (Bundesbank SCT
Bulk OQF - Output Inquiry File)
• /BUB_CT_R21_$SCTQVFBLKCREDTRF (Bundesbank SCT
Bulk QVF - Inquiry Validation File)

Payment Engine (FS-PE)

What’s New in SAP Payment Engine 9.0 PUBLIC 33
 Type
of
Chang
Function e Description More Information

• /BUB_CT_R21_$BBKSCFBLKCDTTRF (Bundesbank SCT

Bulk SCF - Settled Credit File)

The following message IDs were added for the EBA converters
(direct debit):

• /EBA_DD_R21_CAMT.056.001.01 (Interbank Payment Can-

cellation Request (SDD Recall))
• /EBA_DD_R21_PACS.002.001.03 (Interbank Payment Sta-
tus Report (SDD Rejects))
• /EBA_DD_R21_PACS.002.001.03S2 (Interbank Payment
Status Report (SDD))
• /EBA_DD_R21_PACS.003.001.02 (Interbank Direct Debit
(SDD))
• /EBA_DD_R21_PACS.004.001.02 (Interbank Payment Re-
turn (SDD))
• /EBA_DD_R21_PACS.007.001.02 (Interbank Payment Re-
versal (SDD))
• /EBA_DD_R21_$MPEDDDNFBLKDIRDEB (EBA SDD Bulk
DNF - Debit Notification File)
• /EBA_DD_R21_$MPEDDDVFBLKDIRDEB (EBA SDD Bulk
DVF - Debit Validation File)
• /EBA_DD_R21_$MPEDDIDFBLKDIRDEB (EBA SDD Bulk
IDF - Input Debit File)
• /EBA_DD_R21_$MPEDDRSFBLKDIRDEB (EBA SDD Bulk
RSF - Results of Settlement File)

The following message IDs were added for the EBA converters
(instant payments):

• /EBA_IP_R21_CAMT.029.001.03 (Negative Response for a

Recall / Recall by the Originator)
• /EBA_IP_R21_CAMT.056.001.01 (Recall for a SCT Inst
Transaction / Request for Recall by the Originator)
• /EBA_IP_R21_PACS.002.001.03 (Instant Payment Status)
• /EBA_IP_R21_PACS.004.001.02 (Positive Response for a
Recall / Recall by the Originator)

The following message IDs were added for the DK converters

(credit transfer and direct debit):

• /DK_CT_R21_PAIN.001.001.09 (Customer Credit Transfer

Inst DK 3.5 - 2021)
• /DK_CT_R21_CAMT.054.001.08 (Bank to Customer Credit
Notification for SCT Inst DK 3.5 - 2021)

Payment Engine (FS-PE)

34 PUBLIC What’s New in SAP Payment Engine 9.0
 Type
of
Chang
Function e Description More Information

The following new entry is available in the Payment Regu-

lation Release Validity Customizing table for the SEPA Rule-

book changes. See Customizing under Payment Engine File

Handler XML Converter Development Maintain Payment

Regulation Release Validity

• 21th November 2021 for SEPA2021 (new entry)

Legal changes ac- Chang Changes to the MX CBPR+ XML schemas from March 31st 2021 SAP Note 3051055
cording to MX e
and TARGET2 XML schemas from February 26th 2021 are pro-
CBPR+ and TAR-
vided.
GET2
The MX CBPR+ schemas of the following message IDs were
changed:

• /MX_HEAD.001.001.02
• /MX_PACS.002.001.10
• /MX_PACS.004.001.09
• /MX_PACS.008.001.08
• /MX_PACS.009.001.08

The TARGET2 schemas of the following message IDs were

changed:

• /T2_PACS.004.001.09
• /T2_PACS.008.001.08
• /T2_PACS.009.001.08

Payment Engine (FS-PE)

What’s New in SAP Payment Engine 9.0 PUBLIC 35
 Type
of
Chang
Function e Description More Information

Mapping of Busi- New The mapping of the Business Application Header (BAH) and SAP Note 2991584
ness Application
charges of the payment transaction is provided (if applicable) in
Header (BAH) and
the TARGET2 and SWIFT MX inbound and outbound converters
charges in the MX
CBPR+ and TAR- pacs.008 (FI to FI Customer Credit Transfer), pacs.009 (Finan-
GET2 converters cial Institution Credit Transfer) and pacs.004 (Payment Return).

The mapping is implemented according to the RTGS (T2) speci-

fications based on SR 2019 ISO 20022 messages with V01 Busi-
ness Application Header and the Cross-border Payments and
Reporting Plus (CBPR+) specifications based on SR 2019 ISO
20022 messages with V02 Business Application Header, respec-
tively.

The following MX CBPR+ and TARGET2 message IDs are af-

fected:

• /MX_ENV_MSG_SR2020
• /MX_HEAD.001.001.02
• /MX_PACS.004.001.09
• /MX_PACS.008.001.08
• /MX_PACS.009.001.08
• /T2_ENV_MSG_SR2020
• /T2_HEAD.001.001.01
• /T2_PACS.004.001.09
• /T2_PACS.008.001.08
• /T2_PACS.009.001.08

The Payment Engine supports the MX CBPR+ and TARGET2

business messages (pacs or camt) send via "envelope" (/
MX_ENV_MSG_SR2020, /T2_ENV_MSG_SR2020). This enve-
lope contains the business application header (BAH) and the
document containing the business message (e.g. MX pacs.008)
and is used in the inbound and outbound converters. The enve-
lope XML tag is called "Envelope" in MX and "BizData" in TAR-
GET2 messages.

Currently SWIFT FIN messages (MT) and InterAct (MX) are sup-
ported (no FileAct).

Payment Engine (FS-PE)

36 PUBLIC What’s New in SAP Payment Engine 9.0
 Type
of
Chang
Function e Description More Information

MX CBPR+ and New The following new MX CBPR+ inbound and outbound converters Request Agent [page 150]
TARGET2 convert-
are available:
ers SAP Note 3047432
• /MX_CAMT.029.001.09 (Resolution of Investigation V9)
SAP Note 3018935
• /MX_CAMT.054.001.08 (Debit/Credit-Notification V8)
• /MX_CAMT.056.001.08 (Payment Cancellation Request SAP Note 3080510
V8)
SAP Note 3087316
The following new TARGET2 inbound and outbound converters
are available:

• /T2_CAMT.029.001.09 (Resolution of Investigation V9)

• /T2_CAMT.054.001.08 (Debit/Credit-Notification V8)
• /T2_CAMT.056.001.08 (Payment Cancellation Request V8)

These converters are based on the new Request Agent frame-

work introduced with SP07, which is already used in the Instant

Payment converters. In Customizing under Payment Engine

Basic Settings Request Agent Maintain Format Conversion

Information for RA-Activities converter IDs used in a format

conversion step of the request agent can be defined. These are
based on the request agent activities (See Customizing activ-

ity under Payment Engine Basic Settings Request Agent

Development Define Request Agent Activities ).

The following new MX CBPR+ and TARGET2 inbound converters

are available:

• /MX_PACS.002.001.10 (FI to FI Payment Status Report

V10)
• /T2_ADMI.007.001.01 (Receipt Acknowledgement V01)
• /T2_PACS.002.001.10 (FI to FI Payment Status Report V10)

Payment Engine (FS-PE)

What’s New in SAP Payment Engine 9.0 PUBLIC 37
 Type
of
Chang
Function e Description More Information

Improvements in Chang The following improvements of the SWIFT MX CBPR+ and TAR-
MX CBPR+ and e
GET2 converters are available:
TARGET2 convert-
ers • The incoming BAH (Business Application Header) is added
to the file handler data of the incoming order (See SAP Note
3024052 )
• pacs.009 outbound converters: the differentiation between
Core and Cover messages was improved (See SAP Note
3074958 )
• pacs.004 outbound converters: The evaluation of the Origi-
nal Message Name Identification was improved (See SAP
Note 3094414 )

The following improvements of the TARGET2 converters are

available:

• Different mapping of the Message ID (MsgID) of the Group

Header (GrpHdr) in TARGET2 messages compared to MX
messages (See SAP Note3025105 )
• Outbound converters: The time in the Creation Date
(CreDt) of the Business Application Header (BAH) is now
displayed in UTC notation (See SAP Note 3087166 )

Payment Engine (FS-PE)

38 PUBLIC What’s New in SAP Payment Engine 9.0
 Type
of
Chang
Function e Description More Information

Automatic com- Chang Automatic compensation payments can be initiated based on SAP Note 3076799
pensation for in- e
the requested interest compensation or related charges. Subse-
quiry messages SAP Note 3070350
quently, a compensation related outbound pacs.008 can be sent
to the requesting bank.

In detail, creation of compensation orders for an inquiry can

be steered/adjusted via method CHECK_COMPENSATION_RE-
QUIRED of BAdI /PE1/BADI_RA_INQUIRY. In case, a compensa-
tion order is required, a new payment order will be created with
one of the following processes:

• 0271 - Interest Compensation

• 0272 - Charge Compensation

Subsequently, mapping Customizing for the payment or-

der/item can be defined for the respective process via main-

tenance views (Customizing: Payment Engine Clearing

Configuration for Processes ). This will allow for Customizing

payment order type and transaction types as well as derivation
of respective account data.

Moreover, Customizing of view /PE1/V_MAP_PURP might be

required to set a suitable category purpose (e.g. FCOL, INTE,
FCIN) for the respective outbound pacs.008 message.

In turn when receiving an inbound pacs.008 message referring

to a compensation request, the E&V check '253 - Inquiry com-
pensation enrichment' can be added to the E&V check set of
the recipient. Therefore, the relation between compensation
pacs.008 and the related inquiry request agent will be set, thus
allowing to display the related pacs.008 compensation message
as part of the request agent file handler data.

UETR generation Chang New functionality for UUID generation is available with SAP SWIFT MT Converter [page
is RFC4122 com- e Note 2619546 , which enables easier generation of the SWIFT
302]
pliant UETR. Furthermore this functionality is already RFC4122 compli-
ant, hence this part must not be taken care of in the Payment SAP Note 2995730
Engine.

Payment Engine (FS-PE)

What’s New in SAP Payment Engine 9.0 PUBLIC 39
 Type
of
Chang
Function e Description More Information

Value date deter- Chang In case the route calendar is specified in the "calendar determi- Value Date Agreement
mination based on e [page 244]
nation" section in the Value Date Agreement (transaction /PE1/
route calendar
VA), the value date is calculated according to this calendar. So SAP Note 3032515
both calculation and not only shifting to a working day are per-
formed based on the route calendar.

Additionally a new indicator "Shift base date" is introduced in

the "calendar determination" section of the value date agree-
ment. It indicates if the initial base date which is used to calcu-
late the value date shall be shifted according to the calendar
specified in the value date agreement or if the clearing area
value date calendar shall be used. If the indicator is set to
"Yes", the initial base date is shifted according to the calendar
specified in the value date agreement (clearing area value date
calendar or route calendar). If the indicator is set to "No", the
initial base date is shifted according to the clearing area value
date calendar. This is the default option.

Virtual Account New Processing of payments initiated from virtual accounts is now SAP Note 3067765
Management
enabled. Virtual accounts are non-physical accounts used by
bank clients that allow clients to have a central view of all cash
management positions, improve accounts receivable and ac-
counts payable reconciliation, enhance reporting, improve over-
all working capital and provide self-service capabilities. The bank
assigns a range of virtual account numbers. Bank clients have
the flexibility to assign a virtual account hierarchy as they see
fit. Virtual accounts can be provided to customers for payment
purposes, and payments can be made to and from these virtual
accounts.

The new function related to virtual accounts contains the follow-

ing functionality:

• new enrichment and validation checks

• updates in payment processing (request prenote creation
based on the transaction type Customizing)
• new enrichment and validation checks to match the state-
ment entry to forwarded payments
• updates in account management interfaces and proxy
classes

Payment Engine (FS-PE)

40 PUBLIC What’s New in SAP Payment Engine 9.0
 Type
of
Chang
Function e Description More Information

Bank Statement New Processing of bank statements and (intraday) account reports is Virtual Account Manage-
Processing
now enabled and contains the following functionality: ment

• new payment item type 06 "Statement Entry" SAP Note 3023986

• new payment order category 8001 "Statement Processing"
3024447
• enhancement of exception handling
• additional enrichment and validation checks (see SAP Note 3045968

3024447 )
3069001
Scenarios:
3099401
• Data replication for Virtual Account Management:
3088064
• Within Enrichment & Validation it has to derived to
which Target Account in Account Management the
Bank Statement needs to be replicated.
• After defining the Target Account, all Entry Items are
posted in Account Management System.
• Since SAP DM does not support item category "Entry
Item", you need to configure to post the Entry Items as
different item type (recommendation Turn-Over Item).
• There is a duplication check on Entry Item level which
avoids that Entry Items reported from statements
(e.g. camt.053), reports (camt.052) or notifications
(camt.054) are posted multiple.
• With the reconciliation report /PE1/R_RCN_STM_REP-
LICATION_VAM, you can compare if the closing bal-
ance from the bank statement is the same as the ac-
count balance of the virtual account.
• Notification processing for matching:
• The statement processing can also be used to match
notifications (camt.054) with payments (credit trans-
fers).
• SAP Note 3088064 contains an Enrichment & Vali-
dation check which searches for the entry of an corre-
sponding payment item.
• If the original payment item could be found, the for-
warding status is updated.
• In this case the transaction type needs to be defined
with the indicator to skip Clearing & Settlement in or-
der to avoid any postings. With this setting, the Entry
Item processing ends after Enrichment & Validation is
performed.

Payment Engine (FS-PE)

What’s New in SAP Payment Engine 9.0 PUBLIC 41
 Type
of
Chang
Function e Description More Information

• Other scenarios:
• With customer specific Enrichment & Validation meth-
ods and corresponding configuration, additional sce-
narios are possible:
• Reconciliation of Loro/Vostro-Account with posting the
Entry Item to General Ledger (FI Proxy required)
• Replication of Non-Payments related Entry Items (e.g.
Cash Deposits)
• Controlling Cover Payments

New ISO camt.052 A new inbound converter class for Bank Statements is available. Bank Statement Process-
and camt.053 con-
It uses the existing converter framework, but has the following ing
verters for Bank
differences:
Statement proc- SAP Note 3022721
essing • it creates payment orders of category 8001 (Bank State-
ment Processing)
• it maps each entry of the Bank Statement to a payment
item of category 06 (Statement Entry)
• For customer-specific mapping, the existing BAdI /PE1/
BADI_FH_XML_ORDER_IPM is called. The customer-spe-
cific mapping for Statement Entries takes place in method
MAP_AND_CHECK_RCP.

New Customizing is available under Payment Engine File

Handler Bank Statement Converter :

• Determine payment order type: Customizing activity

Determine Payment Order Type
• Determine item transaction type: Customizing activity
Determine Item Transaction Type

New ISO camt.054 A new ISO inbound converter for camt.054.001.08 and Bank Statement Process-
inbound converter
camt.054.001.02 messages is available: ing
for Bank State-
ment processing /ISO_CAMT.054.001.08 (B2C Debit-Credit-Notification V8) SAP Note 3086898

The converter is mapping the camt.054 message into internal

payment orders with entry items. The payment order category
8001 "Statement Processing" shall be used here.

In addition to this new format converter, the existing converters

for ISO camt.052 and camt.053 were updated to support the
version 8.

Payment Engine (FS-PE)

42 PUBLIC What’s New in SAP Payment Engine 9.0
 Type
of
Chang
Function e Description More Information

Handling of er- The handling of error codes received from the account manage- SAP Note 3063395
ror codes from ment system was improved.
account manage-
ment system

Post-or-Cancel for The payment order category 5001 (Internal Transfers) now also SAP Note 3067265
internal transfers
supports the post-or-cancel configuration (See Customizing:

Payment Engine Payment Order Post-or-Cancel )

2.4 Changes and New Features in SAP Payment Engine 9.0

SP09

This table provides an overview of changes and new features that have been introduced in SAP Payment Engine
9.0, SP09.

Type
of
Chang
Function e Description More Information

Request Agent Chang The following new fields are available for the request agent
Timeout Handling e timeout event handling. See the IMG activity under Payment

Engine Basic Settings Request Agent Maintain Time

Configuration .

• Max.No.Exec.: Defines the maximum number of timeout

events that can be triggered.
• Rec.Interval: Defines the elapse time interval between two
timeout events.

This customizing is used in the Time-based Processing Monitor

(transaction /PE1/RA_TIME_MONI).

You can find it under SAP Easy Access Payment

Engine Request Agent Management Time-based Processing

Monitor .

Payment Engine (FS-PE)

What’s New in SAP Payment Engine 9.0 PUBLIC 43
 Type
of
Chang
Function e Description More Information

SEPA Investigation New An additional function is provided to enable the SEPA investiga- Request Agent [page 150]

Processes tion processes.

Payment investigation messages (camt.027) and payment mod-

ification requests (camt.087) allowing for value date adjust-
ments can be triggered for payment items in Edit Payment
Orders (Expert) (transaction /PE1/PO_EXPERT).

Corresponding outbound messages can be created by process-

ing the related request agents in Request Agent Mass Processing
(transaction /PE1/REQ_AGENT_MASS).

When receiving an investigation request, the individual request

can be processed and answered in Manage Request Agents
(transaction /PE1/REQ_AGENT). When processing the related
request agents in Request Agent Mass Processing (transac-
tion /PE1/REQ_AGENT_MASS), the outbound camt.029v8 mes-
sages with the corresponding request status can be generated.

For the generation of outbound messages, configuration

of maintenance view /PE1/V_RA_CONV is required. See

the IMG activity under Payment Engine Basic Settings

Request Agent Maintain Format Conversion Information for

RA-Activities .

Payment Engine (FS-PE)

44 PUBLIC What’s New in SAP Payment Engine 9.0
 Type
of
Chang
Function e Description More Information

Universal Confir- New The function to support payment confirmation for SWIFT MT103 SAP Notes 2898954
mations for MT103 messages is provided. In detail, an outbound MT199 FIN Univer-
and 2911886
sal Confirmations of MT103 messages can be sent to the gpi
tracker.

The new check (check Id 105) needs to be added to the cor-

responding E&V check set. When finalizing the payment, a re-
quest agent of category PC - Payment Processing Confirmation
will be updated and can be processed in Request Agent Mass
Processing (transaction /PE1/REQ_AGENT_MASS). In order to
trigger a suitable MT199 during request agent processing, the
customizing of maintenance view /PE1/V_RA_CONV is required
for agent category PC and conversion activity PAYMPRCCNF.

See the IMG activity under Payment Engine Basic Settings

Request Agent Maintain Format Conversion Information for

RA-Activities .

Moreover, an intermediary MT199 status response can be sent

after a certain period of time. The exact time-based settings
can be configured in the maintenance view /PE1/V_RA_TIME.

See the IMG activity under Payment Engine Basic Settings

Request Agent Maintain Time Configuration .

SWIFT MX Con- New The SWIFT MX converters are provided according to the Cross- SWIFT MT Converter [page
302]
verters border Payments and Reporting Plus (CBPR+) specifications
based on SR 2019 ISO 20022 messages. In detail, the following SAP Note 2918904
converters are delivered:

• pacs.008 (FI to FI Customer Credit Transfer)

• pacs.009 (Financial Institution Credit Transfer)
• pacs.004 (Payment Return)

TARGET2 Convert- New The TARGET2 converters are provided according to the RTGS XML Converter Framework
[page 300]
ers (T2) specifications based on V09 ISO 20022 messages. In de-
tail, the following converters are delivered: SAP Note 2895417

• pacs.008 (FI to FI Customer Credit Transfer)

• pacs.009 (Financial Institution Credit Transfer)
• pacs.004 (Payment Return)

Payment Engine (FS-PE)

What’s New in SAP Payment Engine 9.0 PUBLIC 45
 Type
of
Chang
Function e Description More Information

SWIFT Standards Chang Regulatory SWIFT changes for the SWIFT MT Release 2020 are SAP Note 2898954
MT Release 2020 e provided. The following topics are covered:

• CR 001426: Limit the maximum number of lines starting

with "1/" in 50F and 59F to two occurrences
• CR 001428: Subfield 3 (country code) mandatory for F op-
tion for fields 50 and 59

 Note
Due to the Covid-19 situation, the activation of these topics
has been postponed to 21st November 2021.

Payment Engine (FS-PE)

46 PUBLIC What’s New in SAP Payment Engine 9.0
2.5 Changes and New Features in SAP Payment Engine 9.0
SP08

This table provides an overview of changes and new features that have been introduced in SAP Payment Engine
9.0, SP08.

Type
of
Chang
Function e Description More Information

Legal changes ac- New New XSD schemas are available according to the changes made
cording to the to the SEPA Rulebook 2019, which is valid from 18th November
SEPA Rulebook 2019. The implemented changes are compatible with the follow-
2019 ing rulebooks:

• DK version 3.3 of the appendix 3 of the DFÜ-agreement

• SEPA CT Rulebook 2019
• SEPA DD Rulebook 2019
• EPC SCT Rulebook 2019
• EPC SDD B2B Rulebook 2019
• EPC SDD CORE Rulebook 2019

The following message IDs were added for the EBA converters
(credit transfer):

• /EBA_CT_R19_CAMT.029.001.03
• /EBA_CT_R19_CAMT.029.001.08
• /EBA_CT_R19_CAMT.056.001.01
• /EBA_CT_R19_PACS.002.001.03S2
• /EBA_CT_R19_PACS.004.001.02
• /EBA_CT_R19_PACS.008.001.02
• /EBA_CT_R19_PACS.028.001.01
• /EBA_CT_R19_$SCTCVFBLKCREDTRF
• /EBA_CT_R19_$SCTICFBLKCREDTRF
• /EBA_CT_R19_$SCTIQFBLKCREDTRF
• /EBA_CT_R19_$SCTOQFBLKCREDTRF
• /EBA_CT_R19_$SCTPCFBLKCREDTRF
• /EBA_CT_R19_$SCTSCFBLKCREDTRF

The following message IDs were added for the EBA converters
(direct debit):

• /EBA_DD_R19_CAMT.056.001.01
• /EBA_DD_R19_PACS.002.001.03
• /EBA_DD_R19_PACS.002.001.03S2

Payment Engine (FS-PE)

What’s New in SAP Payment Engine 9.0 PUBLIC 47
 Type
of
Chang
Function e Description More Information

• /EBA_DD_R19_PACS.003.001.02
• /EBA_DD_R19_PACS.004.001.02
• /EBA_DD_R19_PACS.007.001.02
• /EBA_DD_R19_$MPEDDDNFBLKDIRDEB
• /EBA_DD_R19_$MPEDDDVFBLKDIRDEB
• /EBA_DD_R19_$MPEDDIDFBLKDIRDEB
• /EBA_DD_R19_$MPEDDRSFBLKDIRDEB

The following message IDs were added for the EBA converters
(instant payments):

• /EBA_IP_R19_CAMT.029.001.03
• /EBA_IP_R19_CAMT.056.001.01
• /EBA_IP_R19_PACS.002.001.03
• /EBA_IP_R19_PACS.004.001.02
• /EBA_IP_R19_PACS.008.001.02
• /EBA_IP_R19_PACS.028.001.01

The following message IDs were added for the Bundesbank con-
verters (credit transfer):

• /BUB_CT_R19_CAMT.029.001.03
• /BUB_CT_R19_CAMT.029.001.08
• /BUB_CT_R19_CAMT.056.001.01SCT
• /BUB_CT_R19_PACS.002.001.03SCL
• /BUB_CT_R19_PACS.004.001.02SCT
• /BUB_CT_R19_PACS.008.001.02
• /BUB_CT_R19_PACS.028.001.01
• /BUB_CT_R19_$BBKCVFBLKCDTTRF
• /BUB_CT_R19_$BBKICFBLKCDTTRF
• /BUB_CT_R19_$BBKIQFBLKCDTTRF
• /BUB_CT_R19_$BBKOQFBLKCDTTRF
• /BUB_CT_R19_$BBKSCFBLKCDTTRF

The following message IDs were added for the DK converters

(credit transfer and direct debit):

• /DK_CT_R19_CAMT.054.001.02
• /DK_CT_R19_PAIN.001.001.03
• /DK_CT_R19_PAIN.001.001.08
• /DK_DD_R19_PAIN.008.001.02
• /DK_R19_CONTAINER.NNN.001.02
• /DK_R19_PAIN.002.001.03

Payment Engine (FS-PE)

48 PUBLIC What’s New in SAP Payment Engine 9.0
 Type
of
Chang
Function e Description More Information

• /DK_R19_PAIN.007.001.02

The following message IDs were added for the EPC converters:

• /EPC_B2B_R19_PAIN.008.001.02
• /EPC_CORE_R19_PAIN.008.001.02
• /EPC_CT_R19_PAIN.001.001.03

The following new entry is available in the Payment Regulation

Release Validity customizing table for the SEPA Rulebook

changes. See the IMG activity under Payment Engine File

Handler XML Converter Development Maintain Payment

Regulation Release Validity :

• 18th November 2019 for SEPA2019 (new entry)

Payment Engine (FS-PE)

What’s New in SAP Payment Engine 9.0 PUBLIC 49
 Type
of
Chang
Function e Description More Information

Legal changes ac- Chang The SWIFT UETR (Unique End-to-End Transaction Reference) is SWIFT MT Converter [page
302]
cording to the e now used in the following SWIFT converters:
SWIFT Standards
• MTn90 (Message ID /SWIFT_MTN90)
Release 2019
• MTn91 (Message ID /SWIFT_MTN91)
• MTn92 (Message ID /SWIFT_MTN92)
• MTn95 (Message ID /SWIFT_MTN95)
• MTn96 (Message ID /SWIFT_MTN96)
• MTn99 (Message ID /SWIFT_MTN99)

The UETR is available in field f-121 of the SWIFT User Header.

The inbound MTnXX converters map this field into the File Han-
dler data.

The outbound converters map this field through one of the fol-
lowing methods:

1. UETR is copied from the imported SWIFT message (in case

of forwarding)
2. UETR is copied from the original message
3. If UETR is contained in neither SWIFT nor original message,
the UETR is generated according to IETF-Standard RFC
4211 (Version 4)

Additionally the service type identifier (f-111 in the SWIFT

User Header) is mapped in the outbound MTnXX messages,
if the bank is a GPI Closed User Group member. To check
the relevant customizing setting, see the IMG activity under

Payment Engine File Handler SWIFT Format Converter

SWIFT Basic Settings .

The following new cancellation reason codes are available for the
SWIFT MTn92 message:

• AM09 (Wrong Amount - amount received is not the amount

agreed or expected)
• COVR (Cover - cancelled or returned)

The reason codes and additional reason information are mapped

into the corresponding recall fields.

Additionally the format of field f-79 (Cancellation Reason) has

changed that the first line now contains the format /4!c/ for the
cancellation reason code.

The following new entry is available in the Payment Regulation

Release Validity customizing table for the SWIFT Standards Re-

Payment Engine (FS-PE)

50 PUBLIC What’s New in SAP Payment Engine 9.0
 Type
of
Chang
Function e Description More Information

lease 2019. See the IMG activity under Payment Engine File

Handler XML Converter Development Maintain Payment

Regulation Release Validity :

• 17th November 2019 for SWIFT2019 (new entry)

TIPS Convert- New The following XSD schemas were added for the TIPS converters: Upload of Referential Data
[page 174]
ers (Instant Pay-
• /TIPS_R19_ADMI.007.001.01
ments)
• /TIPS_R19_CAMT.029.001.03
• /TIPS_R19_CAMT.056.001.01
• /TIPS_R19_PACS.002.001.03
• /TIPS_R19_PACS.004.001.02
• /TIPS_R19_PACS.008.001.02
• /TIPS_R19_PACS.028.001.01

Additionally the TIPS directory including direct and indirect par-

ticipants can be uploaded via the Referential Data Uploader.

The import can be started with transaction /PE1/UPLOAD_RD

by using the parameter TIP (Data Model) and ECB (Data Pro-
vider).

 Note
Please note that only a full upload is supported.

Payment Engine (FS-PE)

What’s New in SAP Payment Engine 9.0 PUBLIC 51
 Type
of
Chang
Function e Description More Information

Address Informa- New Address information can now be enriched from the business
tion in CAMT.029 partner in the Account Management system in outbound
CAMT.029 messages, in case the following scenario takes place:

• A passive SCT recall is processed with the feedback Sent

request has been rejected.
The rejection code from the request agent field Reference2
is taken to determine the corresponding ISO Code. For

more information, see the IMG activity under Payment

Engine File Handler SEPA Format Converter Map

Reason Code to ISO Code .

If the ISO code is CUST, ARDT, AM04, NOAS or LEGL, an ad-

dress enrichment can be done. To achieve this, the Execute
Action indicator has to be set to Yes in the IMG activity under

Payment Engine File Handler SEPA Format Converter

Enable Address Enrichment for Outgoing SEPA Messages .

The business partner is determined via the Account Manage-

ment Proxy. The web service
(PaymentTransactionProcessingManageBusinessPartne
rOut) retrieves the address information for the business part-
ner. This information is written into the AddtlInf XML-tags of
the outbound CAMT.029 message (see the fallback implementa-
tion of BAdI /PE1/BADI_RA_ADDRESS).

Payment Engine (FS-PE)

52 PUBLIC What’s New in SAP Payment Engine 9.0
 Type
of
Chang
Function e Description More Information

Different Error Co- New The business object Exception (database table /PE1/ Exception Control (FS-PE-
des for AM Con- DB_EH_FCHCK) was extended with the attribute Differentiation EH) [page 265]
nection Issues Value. This new attribute has the approach to differentiate ex-
ceptions with additional information in place of duplicating exist-
ing Exception IDs as variants.

The first use cases for differentiation value attribute are the
RFC-based Account Management (AM) Proxies for SAP Account
Management. The exceptions triggered from these AM Proxy
classes are enriched now with the underlying process (for ex-
ample, posting, disposition, and so on). This information allows
defining different rules in the Exception Control.

 Example
• If the RFC connection cannot be established, then the
item can be handed over to Exception Control where EH
Error ID 001000 (Connection Error) is used.
• In Exception Control, you can define for prenote crea-
tion (Differentiation Value = PRX002) to reject the pay-
ment order.
• For Posting Requests (Differentiation Value = PRX003),
you can define for the same Error ID 001000 to retry
immediately or with delay.

DK PAIN.002 (Cus- Chang A new field (indicator) No ACCP is added in the Order Type ID
tomer Payment e customizing. If this indicator is set, then the accepted items are
Status Report) not included in the PAIN.002 message.

To check the relevant customizing setting, see the IMG activity

under Payment Engine File Handler Status Notification

Define Notification Templates .

Payment Engine (FS-PE)

What’s New in SAP Payment Engine 9.0 PUBLIC 53
 Type
of
Chang
Function e Description More Information

Updated Synchro- Chang The synchronous FSN web service consumer

nous FSN Service e (PaymentTransactionConnectorManagePaymentTransact
ionMessageOut) was updated to populate the message header
with references to Payment Engine (PE) business objects.

The Message Header ID is populated with the business key of

the Object List. The Reference ID is populated with the key of the
underlying business object (Payment Order or Request Agent)
which has been used for the conversion.

This improvement is helpful for tracking purposes where the

exchanged payload does not need to be converted to retrieve
references.

Updated Chang In the context of SEPA Instant Payments, the transaction refer-
PACS.002 Instant e ences (XML-Tag TxInfAndSts) should always be available in the
Payment Inbound PACS.002 message.
Converter
This correction is for internal integration purposes and for the
unexpected situation where the original transaction details are
not provided.

With this update, the required transaction information is re-

trieved internally based on the original Message ID, if not pro-
vided externally.

DK c5n Converter New A new outbound converter is provided corresponding to

XSD schema /DK_CT_R19_CAMT.054.001.02 (ISO Schema
CAMT.054.001.02) for the Bank to Customer Credit Notification
for SCT Inst DK 3.3, which is valid as of November 17, 2019.

It is used to notify the payee of SCT Instant Payment of an entry

which has been credited to its account.

A new field (indicator) Payee Notif. is added in the Item Type ID

customizing. If this indicator is set, then the status notification is
sent to the payee. Otherwise, it is sent to the ordering party of a
payment.

To check the relevant customizing setting, see the IMG activity

under Payment Engine File Handler Status Notification

Define Notification Templates .

Payment Engine (FS-PE)

54 PUBLIC What’s New in SAP Payment Engine 9.0
2.6 Changes and New Features in SAP Payment Engine 9.0
SP07

This table provides an overview of changes and new features that have been introduced in SAP Payment Engine
9.0, SP07.

Function Type of Change Description More Information

Instant Payments New It is now possible to send and receive For more information on
instant payments in the Payment the customizing steps
Engine. The following entires show needed for setting up in-
the functions, which were added or stant payments, see the
changed to enable this new function- IMG organizational activity
ality. Payment Engine SEPA
Additionally new message IDs were SEPA Instant Payments
created for the instant payments
Configuration
converters (see transaction /PE1/
XSD):

• /
EBA_IP_R18_CAMT.029.001.
03
• /
EBA_IP_R18_CAMT.056.001.
01
• /
EBA_IP_R18_PACS.002.001.
03
• /
EBA_IP_R18_PACS.004.001.
02
• /
EBA_IP_R18_PACS.028.001.
01
• /
DK_CT_R19_PAIN.001.001.0
8

Furthermore it is now possible to use

the Free Message Service
(PaymentTransactionConnector
ManagePaymentTransactionMess
ageOut) to exchange messages for
the message types used in the re-
quest agent (CAMT.029, CAMT.056).

Payment Engine (FS-PE)

What’s New in SAP Payment Engine 9.0 PUBLIC 55
Function Type of Change Description More Information

Payment Processing based New A new attribute for the payment

on System Date & Time
order type configuration was intro-
duced. With this option the payment
order is processed based on system
date and time. This means the plan-
ned execution date and time is com-
pared with the system date and
time instead of with the functional
date and time.

Example:

 Example
A customer submits a credit
transfer where the requested ex-
ecution time is (for example,
08:00 p.m. CET).

In the standard approach (without

using this option) the payment or-
der is processed with the start of
EOD (for example, 07:30 p.m. CET)
because the functional time is set
to 11:59:59 p.m. in order to finalize
all payment orders from the current
posting date.

With the usage of system date and

time as a basis, the order is proc-
essed when the requested execution
time is reached during processing or
with the next STP POLLER job run.
This change also affects the compari-
son attribute Time in rule sets. If the
payment order type is defined to use
the system date and time, then the
comparison time is the system time
and not the functional time.

Limitation:

If this processing option is chosen

for 24/7 processing then it is recom-
mended to also use an adequate cal-
endar in the clearing area settingsl.
In E&V the validations regarding cut-
off time and planned processing date
should not be used since this func-

Payment Engine (FS-PE)

56 PUBLIC What’s New in SAP Payment Engine 9.0
Function Type of Change Description More Information

tion is designed to process at any

time.

Time-based Processing Mon- New The time-based processing

itor monitor (Application menu

Payment Engine Request

Agent Management Time-based

Processing Monitor ) can be used to

trigger timeout events for a request
agent after a certain amount of time
has passed without receiving a re-
sponse.

Currently you can trigger an out-

bound PACS.028 message for a re-
quest agent of type C1 (Interbank
Payment with Confirmation Monitor-
ing) or an outbound PACS.002 mes-
sage for a request agent of type C2
(Interbank Payment with Confirma-
tion).

Payment Engine (FS-PE)

What’s New in SAP Payment Engine 9.0 PUBLIC 57
Function Type of Change Description More Information

Processing with Post-Or-Can- New For online channels a new processing

cel Option attribute called Post-Or-Cancel has
been introduced. This option checks
whether the processing result of the
whole payment order is either suc-
cessful (internal items are posted)
OR rejected (cancelled). If the proc-
essing is neither then a rejection of
the order is triggered.

The background behind this function

is that some online channels are not
interested or cannot handle pending
processing results (Post Processing,
Asynchronous Posting, etc.). It there-
fore has to be ensured that the caller
gets a final response (completely
processed or rejected). This new
processing option helps to avoid con-
figuration errors which lead to proc-
essing results with pending objects.

To use this option you have

to maintain it in IMG activity

Payment Engine File Handler

Financial Message Services

Integration Control Payment Order

Process .

If you use this option then you

have to also maintain which Excep-
tion Handling (EH) reaction for pay-
ment order rejections has to be
used. You can find this new IMG ac-

tivity here under Payment Engine

Payment Order Define Post-or-

Cancel rejection response type

There you can also find the BADI

where you can overwrite the condi-
tions for triggering the rejection more
precisely to suit your business needs.

 Note
This processing option also re-
quires some changes in the ex-

Payment Engine (FS-PE)

58 PUBLIC What’s New in SAP Payment Engine 9.0
Function Type of Change Description More Information

isting RFC- based Account Man-

agement Proxy. If thePost-Or-
Cancel setting is used, then it
is also handed over to BAPI in-
terfaces for posting in FS-AM. If
a material check fails then the
posting request will be rejected.
In this case the response mes-
sage is always E148. In order
to still derive the functional re-
jection reason, the Payment En-
gine internal error ID for excep-
tion handling is derived based
on the return table. This re-
quires you to also maintain the

IMG activity: Payment Engine

Posting Interfaces DM Proxy

Response Assign AM Error

Codes to PE

Furthermore, if Post-Or-Cancel is
used then the item packaging is not
used. Items are always posted di-
rectly.

Finally, if the Post-Or-Cancel setting

is used then connection errors are
not handled by switching to asyn-
chronous processing mode. The item
is handed over to EH with error ID
001000 depending on the situation
for phases 000050 (posting prepara-
tion) or 000100 (posting).

Payment Engine (FS-PE)

What’s New in SAP Payment Engine 9.0 PUBLIC 59
Function Type of Change Description More Information

Support of FS-AM Reconcili- New In Version 2 of the reconciliation pro-

ation Version 2 cedure, SAP Account Management
(FS-AM) provides the comparison
based on transfer date. You can find
in FS-AM the description of this pro-
cedure and the impact of version
2 in the documentation of table
BCA_RCN_SUMS_INA.

With this correction FS-PE supports

the usage of reconciliation procedure
Version 2. In this reconciliation pro-
cedure, posting dates in Payment En-
gine (FS-PE) and Account Manage-
ment (FS-AM) do not have to be in
synch.

Payment Engine (FS-PE)

60 PUBLIC What’s New in SAP Payment Engine 9.0
Function Type of Change Description More Information

New Request Agent Frame- New A new processing framework for re-
work (Request Agent Process
quest agents has been created that
Orchestration)
simplifies handling and allows for
more flexible extensions. This new
request agent processing framework
is compatible with existing function-
ality. Its usage depends on the imple-
mentation of the corresponding re-
quest agent type.

Request agent processing options

have been simplified:

• Only one processing option

"Process" is now needed (in-
stead of the previous processing
options Forward, Request and
Process.
• During execution details are de-
rived automatically by the corre-
sponding request agent type.

Similarly, the request agent status

handling has been simplified. Instead
of multiple statuses for each proc-
essing option only two major status
are required:

• Request agents can be proc-

essed (request agent status 30
- Feedback Received)
• Request agents are waiting for
an external event (request agent
status 25 - Feedback Requested)

The next processing steps to be exe-

cuted are determined by the corre-
sponding request agent type. The list
of steps and the corresponding data
is stored separately from the request
agent data. This approach allows for
a flexible number of executed proc-
essing steps.

In addition, data storage has been

improved in two ways:

• The request agent types allow

for "typed" data. This makes the

Payment Engine (FS-PE)

What’s New in SAP Payment Engine 9.0 PUBLIC 61
Function Type of Change Description More Information

previous "data" fields superflu-

ous.
• Business data can be stored to-
gether with the executed proc-
essing steps. This allows for a
flexible amount of data to be
stored with the request agent.

Outgoing message generation is de-

coupled from implementation of spe-
cific request agent types. This ap-
proach allows for an easy extension
if new formats need to be created,
since only a new converter format
needs to be implemented instead of
creating/copying new request agent
types each time slight changes in the
format converters are required.

In addition, asynchronous process-

ing capabilities of the request agent
have been improved. It is now pos-
sible to receive external events for
locked request agents. In this case,
event steps are added to the request
agent processing queue and can be
processed later via a batch report.
Alternatively, a new request agent
type allows you to execute event re-
ception asynchronously. This can be
usefuls, for example, if the events are
received prior to the original trans-
action and a corresponding request
agent to receive the event does not
exist at the time the event is re-
ceived.

Payment Engine (FS-PE)

62 PUBLIC What’s New in SAP Payment Engine 9.0
Function Type of Change Description More Information

New Clearing Option to Post New A new clearing option was intro-
with Posting Date from Ac- duced for internal clearing agree-
count Management System ments which are set up for direct
posting. This new option can be used
if the system is set-up to process
payments on more business days
(e.g. 365/24/7) then the connected
Account Management (e.g. TARGET
business days). Without using this
option the standard approach is
to queue postings on non-business-
days according to AMS until the next
business day in AMS is reached. By
using this clearing option the PE-in-
ternal Posting Date is adjusted to
the next Posting Date according to
the Account Management and will
be posted immediately. This clearing
option can be helpful for Real-Time
scenarios.

 Note
The usage requires the capability
in the connected Account Man-
agement System to support fu-
ture dated postings. To validate
and adjust the posting date ac-
cording to AMS calendar means
the same calendar has to be
used in the clearing agreement
or route as is used in the Ac-
count Management System. If
this option is used, the posting
date is transferred in the posting
request to AMS - independent
from the customizing settings.

Payment Engine (FS-PE)

What’s New in SAP Payment Engine 9.0 PUBLIC 63
Function Type of Change Description More Information

New Option for Decoupled New A new option has been introduced
Posting of Clearing Items for external clearing agreements to
always decouple the posting of clear-
ing items from sending the outgoing
payment order to the output man-
ager. When this option is chosen, the
clearing item is not posted until the
recipient item has reached the final
state 34.

This option is only available for single

processing of payment items.

New Option for Parallel Post- New Usually the asynchronous poller
ing of Payment Items processes payment items that be-
long to the same account within the
same package. A new option has
been introduced to transfer payment
items with the same account in par-
allel to the account management sys-
tem. It's important to mention that
this option only makes sense if the
corresponding account allows paral-
lel postings (no balance checks).

With this option it is possible to ach-

ieve a higher throughput of payment
items and can be used, for example,
for posting to a clearing account.

The option can be activated in

the IMG under Payment Engine

Posting Interfaces DM proxy

Posting Maintain AM transaction

type (Option Parallel)

Payment Engine (FS-PE)

64 PUBLIC What’s New in SAP Payment Engine 9.0
Function Type of Change Description More Information

New Reference Date for New Previously the asynchronous poller

Value Date Determination processed payment items that be-
long to the same account within
the same package. A new option
has been introduced that allows you
to transfer payment items with the
same account in parallel to the ac-
count management system. It is im-
portant to mention that this option
only makes sense if the correspond-
ing account allows parallel postings
(no balance checks).

With this option it is possible to ach-

ieve a higher throughput of payment
items. It can be used, for example, for
the posting to a clearing account.

The option can be activated in

the IMG under Payment Engine

Posting Interfaces DM proxy

Posting Maintain AM transaction

types (Option Parallel)

New Payment Order Proc- New A new payment order processing cat-
egory has been introduced that al-
essing Category
lows final processing based on the
response of a positive confirmation
status. This processing behavior is
recommended, for example, when re-
ceiving SEPA instant payments. In
this case, final processing of the pay-
ment order is stalled until a positive
external response has been received.

Payment Engine (FS-PE)

What’s New in SAP Payment Engine 9.0 PUBLIC 65
Function Type of Change Description More Information

FH Data Display Changed File handler data display has been

improved to make complex payment
message sequences visible at a
glance. To that end, the file han-
dler data display control has been
improved within the PO Expert and
Request Agent UI. All related financial
messages of the same object and of
related objects are now displayed to-
gether with their respective file han-
dler data. Moreover, it is possible to
display the message overview in full
screen mode. Alternatively, you can
choose to restrict the file handler
data displayed to the current object
only.

Adjustment data selection of Changed In order to accelerate EOD (End of

EOD programs Day) processing, the following batch
jobs were optimized regarding data
selection:

• Accrual
• Date Increase
• Finalize Incoming Order
• Finalize Outgoing Order
• Update Future Dated Postings

These programs now only select or-

ders up to the EOD closing date. The
advantage of this selection is that
new orders (for example, from real-
time channels which are submitted
during EOD) are no longer selected.

Payment Engine (FS-PE)

66 PUBLIC What’s New in SAP Payment Engine 9.0
Function Type of Change Description More Information

OPM Stream Class Changed The OPM Stream Class /PE1/

CL_OPM_OUTPUT_STREAM_FREE
uses the synchronous web service
consumer
PaymentTransactionConnectorM
anagePaymentTransactionMessa
geOut to exchange messages. With
this change the behavior regarding
encoding the payload with base-64
and the event to send the payload is
controlled by the customizing
view /PE1/V_FSNMSGTY2.

The encoding with base-64 takes

place only if it is configured. If you
already use the OPM Steam Class,
please take into account that after
this change the payloads won't be
encoded with base-64. The default
behavior will change to deliver Text/
XML-String.

By setting the attribute Send on

Commit you can define that the pay-
load will be sent after the payment
processing is technically finished.
Without this option the payload will
be sent immediately during order
processing. This setting can avoid
rare situations where technical er-
rors can occur which cause the pay-
ment processing to be reverted (rol-
led back) but the (financial) message
to be sent out.

Finally, please take into account

that the synchronous response of
the web service is handed over to
the forwarding status framework.
This allows you to track on the cor-
responding Payment Engine object
(for example, the payment order),
whether the payload could be sent
successfully. You can define the for-
warding status in the IMG activity

- Payment Engine File Handler

External Response .

Payment Engine (FS-PE)

What’s New in SAP Payment Engine 9.0 PUBLIC 67
Function Type of Change Description More Information

Update Web Service Opera- Changed The operation CreateOrder from web
tion CreateOrder service
PaymentTransactionProcessingMana
gePaymentTransactionOrderIn previ-
ously mapped the XML Element
<BankAccountDocumentReconciliati
onKeyID> into the corresponding
fields of payment order reconciliation
data without mapping the item rec-
onciliation data.

With this change the mapping logic is

harmonized which means that the
externally provided reconciliation
data in XML Element
<BankAccountDocumentReconcil
iationKeyID> is mapped for both
order and item reconciliation data.

Additionally the mapping logic for

creating external payment notes as
payment remittances was optimized.

Exception Phase for External Changed Exception handling (EH) configura- Overall Upgrade Sequence
tion for external status responses
Status Update
has been consolidated into a sin-
gle new EH-process 68 - External
Status Reponse. The new configura-
tion simplifies customizing for exter-
nal status responses of incoming
and as well as outgoing payment
orders as part of the same "proc-
ess". Existing configurations of phase
External Status Update" within proc-
ess Outbound File Processing can
be migrated by executing the cor-
responding migration report /PE1/
R_MIG_ESR_RULESET.

Payment Engine (FS-PE)

68 PUBLIC What’s New in SAP Payment Engine 9.0
2.7 Changes and New Features in SAP Payment Engine 9.0
SP06

This table provides an overview of changes and new features that have been introduced in SAP Payment Engine
9.0, SP06.

Function Type of Change Description More Information

Payment regulation release New A new customizing is available,

validity customizing where you can define the validity of
a payment regulation release using a
start date and time:

Payment Engine File Handler

XML Converter Development
Maintain Payment Regulation Release
Validity

SAP delivers the following predefined

dates:

• 18th November 2018 for

SEPA2018 (SEPA Rulebook
2018)
• 18th November 2018 for
SWIFT2018 (SWIFT Standards
Release 2018)

Payment Engine (FS-PE)

What’s New in SAP Payment Engine 9.0 PUBLIC 69
Function Type of Change Description More Information

Legal changes according to New New XSD schemas are available ac-
the SEPA Rulebook 2018 cording to the SEPA Rulebook 2018
changes, which is valid from 18th
November 2018. The implemented
changes are compatible with the fol-
lowing rulebooks:

• DK version 3.2 of the appendix 3

of the DFÜ-agreement
• SEPA CT Rulebook 2018
• SEPA DD Rulebook Core 2018
• SEPA DD Rulebook B2B 2018

The following message IDs were

added for the EBA converters (credit
transfer):

• /
EBA_CT_R18_PACS.028.001.
01
• /
EBA_CT_R18_CAMT.029.001.
03
• /
EBA_CT_R18_CAMT.056.001.
01
• /
EBA_CT_R18_PACS.002.001.
03S2
• /
EBA_CT_R18_PACS.004.001.
02
• /
EBA_CT_R18_PACS.008.001.
02
• /
EBA_CT_R18_$SCTCCFBLKCRE
DTRF
• /
EBA_CT_R18_$SCTCVFBLKCRE
DTRF
• /
EBA_CT_R18_$SCTICFBLKCRE
DTRF

Payment Engine (FS-PE)

70 PUBLIC What’s New in SAP Payment Engine 9.0
Function Type of Change Description More Information

• /
EBA_CT_R18_$SCTPCFBLKCRE
DTRF
• /
EBA_CT_R18_$SCTSCFBLKCRE
DTRF

The following message IDs were

added for the Bundesbank convert-
ers (credit transfer and cheque):

• /BUBA_CH_$BBKRSFBLKSVV
• /
BUB_CT_R18_CAMT.029.001.
03
• /
BUB_CT_R18_CAMT.056.001.
01SCT
• /
BUB_CT_R18_PACS.002.001.
03SCL
• /
BUB_CT_R18_PACS.004.001.
02SCT
• /
BUB_CT_R18_PACS.008.001.
02
• /
BUB_CT_R18_PACS.028.001.
01
• /
BUB_CT_R18_$BBKCVFBLKCDT
TRF
• /
BUB_CT_R18_$BBKICFBLKCDT
TRF
• /
BUB_CT_R18_$BBKSCFBLKCDT
TRF

New converter implementations

were created for the following mes-
sage IDs:

• /BUBA_CH_$BBKRSFBLKSVV
• /EBA_CT_R18_PACS.028.001.01

Payment Engine (FS-PE)

What’s New in SAP Payment Engine 9.0 PUBLIC 71
Function Type of Change Description More Information

Request for recall by the orig- New The request for recall by the origina-
inator tor scenario can be now applied in
the Payment Engine using a recall

group in Payment Engine Recall

Maintain Recall Groups . .

In addition, it is possible to specify

whether an additional recall reason
information can be maintained via
the Recall user interface (Prevent
additional recall reason information

flag in Payment Engine Recall

Assign Recall Reasons to Recall

Groups or Types ).

Additionally, a new inbound

PACS.028 (Request for Sta-
tus Update) converter is
now available (Message
ID: /EBA_CT_R18_PACS.028.001.01),
which creates a request agent. In the
forwarding scenario of the request
agent, an outgoing PACS.028 mes-
sage is created.

The mapping of additional reason in-

formation and cancellation ID was
added in the following converters:

• PACS.004 (outbound)
• CAMT.029 (inbound and out-
bound)
• CAMT.055 (inbound)
• CAMT.056 (inbound and out-
bound)

Recall search in archive New Recalls search items in archive, if the

archive flag for the recall group is
set in customizing and no item is
found in the database. To support
this search, a new archiving infos-
tructure (/PE1/PI_AIS) has been
delivered for archiving object /PE1/
ORD2.

Payment Engine (FS-PE)

72 PUBLIC What’s New in SAP Payment Engine 9.0
Function Type of Change Description More Information

File Handler data in request Changed The File Handler data in the request Request Agent [page 150]
agent UI is now displayed with a
agent
dropdown (that is, no longer on mul-
tiple tabs).

SWIFT UETR (SWIFT Stand- New New functionality related to the SWIFT MT Converter [page
ard Release 2018) SWIFT Standards MT Release 2018 is 302]
available:

• The mapping of the unique end-

to-end transaction reference
(UETR, f-121 in the SWIFT User
Header) is mandatory for the
MT103(+), MT202(cov) and
MT205(cov) message types.
• In case the UETR is not pro-
vided in the file, a new UETR
is generated (according to the
IETF-Standard RFC 4211 (Ver-
sion 4)) and forwarded in the
outbound message. To use this
functionality the new recipient
item E&V check (check ID 439)
must be added into the recipient
item check set.
• In the cover payment scenario,
the UETR from the MT103 mes-
sage is copied unchanged into
the MT202cov message.
• The service type identifier
(f-111 in the SWIFT User
Header) is mapped in the
outbound message, if the
bank is a GPI Closed User
Group member (see Cus-

tomizing under Payment

Engine File Handler SWIFT

Format Converter SWIFT

Basic Settings ).
• For all other MT1* and MT2*
message types these changes
only apply, in case of a GPI-
CUG member (Global Payment
Innovation - Closed User Group
member).

Payment Engine (FS-PE)

What’s New in SAP Payment Engine 9.0 PUBLIC 73
Function Type of Change Description More Information

Non-live BIC New In the BIC-Directory 2018 from Referential Data Interface
SWIFTRef, a new characteristic is
(FS-PE-RDI) [page 172]
available to determine whether the
BIC is a non-live BIC. This character-
istic (BIC Connection Status) is now
evaluated in the Payment Engine and
can be used in routing control to dis-
tinguish if the BIC of a payment item
is a non-live BIC.

New SWIFT reason codes New For the SWIFT messages MTn92 and
MTn96, the return reason and re-
sponse code from ISO20022 are now
available.

Archiving master data New New archiving objects for master • Archiving (FS-PE-ARC)
data objects are introduced: [page 420]

• /PE1/BFC: Bank File Clearing • Archiving Bank File

• /PE1/VA: Valuta Rulesets Clearing [page 434]

• /PE1/RN: Routes and Clearing • Archiving Value Date

Agreements Data [page 435]
• Archiving Routes and
Clearing Agreement
Data [page 435]

Change position of a rule in a Changed In all ruleset you can now change the Rule Set [page 188]
ruleset position of a rule directly by using the
context menu (that is, without using
drag-and-drop).

2.8 Changes and New Features in SAP Payment Engine 9.0

SP04

This table provides an overview of changes and new features that have been introduced in SAP Payment Engine
9.0, SP04.

Function Type of Change Description More Information

New Eurogiro format New The Eurogiro now supports format Eurogiro [page 305]
MT198-93 in the incoming and the
outgoing channel.

Payment Engine (FS-PE)

74 PUBLIC What’s New in SAP Payment Engine 9.0
Function Type of Change Description More Information

SWIFT standard outgoing Changed SWIFT outgoing channel (category 1

channel and 2 messages) including Eurogiro
derivatives (MT103 and MT198-93))
now have a BRF+ for tags 50-59.
This rule set determines the output
options within the outgoing channel.
It allows you to define output options
at customer level.

You can also choose the following to

determine the party identifier or ac-
count information in the swift tag op-
tion:

• Whether the account number

should be taken over into the ac-
count area, or the IBAN;
• Whether the national clearing
code should be taken over into
the party identifier area, or the
BIC;

If the rule set contains no values, the

preferred options defined in the cod-
ing are used;

Correction Rules New If you have set up an exception han- Correction Rules [page 270]
dling reaction type for manual post-
processing (for a payment order or
payment item), you can set up your
system in such a way that it analyzes
the manual changes made during
this processing step to see if it can
detect recurring correction patterns
that could potentially be automated.

Payment Engine (FS-PE)

What’s New in SAP Payment Engine 9.0 PUBLIC 75
Function Type of Change Description More Information

FX Country Conversion New You can define at SLA level, that

the transaction currency is converted
into the destination country cur-
rency. Here are examples of how to
configure the scenarios::

• For bank payments, the com-

mon way is to do this only for
the recipient item (and not for
the whole order) as a recipient
item cross check via E&V config-
uration.
• For customer payments, the en-
tire order (including all items
(for example, ORP, fee)) is con-
verted into the destination coun-
try currency as a cross-item
check via the E&V configuration.

The above mentioned scenarios are

common ways to configure, but it
is also possible to use the recipient
item check for customer payments
and vice versa.

Extension of SLA rule set for New You can specify for SLA rule sets
charge determination used to determine condition types
and condition groups which of the
following should be used to calculate
charges:

• The first applicable rule

• all applicable rules across all
SLA hierarchies;

Correspondence Printing New You can now trigger the printing of Start Correspondence Print-
the following objects by code words. ing [page 411]

• execution confirmation
• incoming advice note
• liquidity advice note

Application Log New Log entries that are generated

through simulation runs are now
listed in separate simulation log
blocks.

Payment Engine (FS-PE)

76 PUBLIC What’s New in SAP Payment Engine 9.0
Function Type of Change Description More Information

Internal Collectors Changed The criteria for internal collectors

(ordering party or ordering recipient
item) now take into account the ac-
count currency as well as the trans-
action currency.

Interbank Charges Changed Interbank charges for outgoing pay-

ments for banks via clearing systems
or SWIFT are now determined as fol-
lows:

In incoming enrichment and valida-

tion checks, the BIC of the external
recipient item is used to try to de-
termine a service level agreement
(SLA). SLA hierarchy levels are also
taken into account. The charge from
the inter-bank charge process is cal-
culated using information from the
external recipient's SLA hierarchies.

SAP Fiori app New The SAP Fiori apps Manage

Correction Rules is now available.

Deletion of Payment Orders New Payment orders that have been cre-
ated in SAP Fiori app Create Payment
Order and remain in status draft for
a predefined number of days (resi-
dence time) can be deleted on a reg-
ular basis using a background report.

You define the residence time in Cus-

tomizing under Payment Engine

UI Maintain Draft Residence

Time ;

Customizing New The following new activities or nodes See Customizing documen-
have been added in Customizing for
tation
Payment Engine:

• Exception Control Basic

Settings for Exception Handling
Automatic Postprocessing
(Learning)

• File Handler SWIFT Format

Converter Define Customer

Instruction Code

Payment Engine (FS-PE)

What’s New in SAP Payment Engine 9.0 PUBLIC 77
2.9 Changes and New Features in SAP Payment Engine 9.0
SP03

This table provides an overview of changes and new features that have been introduced in SAP Payment Engine
9.0, SP03.

Function Type of Change Description More Information

Charges: Maintaining condi- New You can now maintain condition

tion groups from the SLA groups from within a service level
agreement (SLA) by carrying out the
following steps:

1. Call up the relevant SLA by

choosing Payment Engine

Master Data Service Level

Agreements Manage Service

Level Agreements (transac-

tion /PE1/SLA). Switch to edit
mode.
2. Go to the tab Charges.
3. For Charge Processing choose
Set of Rules.
A Charge Calculation and
Processing section opens.
4. Double-click on the rule set in
question. A popup with the rule
set details appears.
5. Choose Manage Condition
Groups to branch to a screen
where you can create a new con-
ditions groups or change the ex-
isting one.
6. Save your changes.

Payment Engine (FS-PE)

78 PUBLIC What’s New in SAP Payment Engine 9.0
Function Type of Change Description More Information

Rule Sets for Foreign Ex- New You now have the option of defin- For details on the check set-
change Predefined Rates
ing multiple rules for checking prede- tings, see the field documen-
fined foreign exchange rates per SLA. tation in the rule set.

Per rule, you can define the following:

• What criteria needs to be met

for the rule to apply (For exam-
ple, only to specific channels,
and/or currency groups);
• Whether a predefined rate is:
• Never allowed
• Always allowed
• Allowed only if it is within
the specified tolerance
range;
• Allowed/disallowed based
on the settings of the next
higher SLA;
• If a check is carried out: The
percentage and/or spread range
to check against;

The first matching rule found (based

on the sequence in the rule set) is
applied.

To create a rule set for checking pre-

defined FX rates, take the following
steps:

1. Call up the relevant SLA by

choosing Payment Engine

Master Data Service Level

Agreements Manage Service

Level Agreements . Switch to

edit mode.
2. Go to the tab Foreign Exchange.
3. For FX Predefined Rate, choose
Set of Rules.
4. In section Predefined Rate for
Foreign Exchange, choose Create
Rule:
• Specify the selection crite-
ria that need to be met for
the rule to apply.

Payment Engine (FS-PE)

What’s New in SAP Payment Engine 9.0 PUBLIC 79
Function Type of Change Description More Information

• Specify if a predefined
rate is allowed, and if so,
whether it needs to be
checked.
• If applicable: Enter the per-
centage and/or spread fac-
tor to check against.
5. Save your entries.

Maintaining Converter Attrib- New You can now also define a code page
ute Code Page as an attribute to be used by the File
Handler to handle incoming and out-
going files.

You can add this attribute in Custom-

izing under Payment Engine File

Handler Basic Settings Maintain

Converter Attributes .

2.10 Changes and New Features in SAP Payment Engine 9.0

SP02

This table provides an overview of changes and new features that have been introduced in SAP Payment Engine
9.0, SP02.

Function Type of Change Description More Information

Charge detail information New The charge calculation process now

also creates structured charge item
detail information using configurable
text modules.

These text lines can be transferred

together with the posting to the ac-
count system.

Payment Engine (FS-PE)

80 PUBLIC What’s New in SAP Payment Engine 9.0
Function Type of Change Description More Information

Charges request control at New You can now set charge request con- To set this parameter, go
SLA level trol parameters in the SLA. to the Charges tab in the
SLA and select the Charge
You can choose beween the following
Processing rule set in ques-
options:
tion. Here you can specify
• ' ' - Charge request type ac- the relevant Charge Request
cording to account type (for Option.
loro accounts a charge advice,
for nostro accounts a charge re-
quest)
• 01 - Force charge advice (an
MT190 is created)
• 02 - Force charge Request (an
MT191 is created)
• 03 - No charge request is cre-
ated

Charge type adjustment New The revised Directive on Payment The cross item check
Services (PSD2) allows only charge 71 "Charge Type
option Share (SHA) in SEPA pay- Adjustment" implements
ments. For this reason, a new E&V this functionality.
check has been introduced to replace
The replacement takes place
the charge type automatically.
only for customer initiated
payments inside SEPA coun-
tries.

New incoming E&V check New You can now check that an internal
account exists in a DM (Deposits
Management) system.

The check can be used for the follow-

ing account types:

• ordering party account

• recipient order account
• charges account

If the check does not find an active

account in the currency entered in
SAP Payment Engine, it triggers an
exception, which Exception Handling
can react upon.

Payment Engine (FS-PE)

What’s New in SAP Payment Engine 9.0 PUBLIC 81
Function Type of Change Description More Information

Duplicate check New You can now define which fields See Customizing documen-
should be taken into account when tation under Payment
checking for duplicate entries. You
Engine Payment Order
do this by defining a Duplicate Check
Group, which you assign in Customiz- Payment Order Enrichment
ing at order type and channel level. and Validation Check
Specific Configuration

Maintain Field Set for

Duplicate Check V3 ;

Separation of technical New Technical queues can now be sepa- See Customizing documen-
queues rated by payment item category. tation under Payment

Engine Clearing Specify

Collection Criteria for

Technical Queues

UI - Creating private tem- New You can now mark templates for
plates creating, managing, or repairing pay-
ment orders as private.

Private templates are visible to the

user that created them. They can-
not be changed or deleted by other
users.

UI - Customizing New For the SAP Fiori app My Inbox you Setting up Additional Search
can add additional search criteria at Criteria for Orders and Items
order and at item level, which can be [page 395]
used as criteria to filter orders and
items within the App.

Payment Engine (FS-PE)

82 PUBLIC What’s New in SAP Payment Engine 9.0
Function Type of Change Description More Information

UI - New configuration op- New You can now specify on a more See:
tions for selection of for- detailed level which format/me-
• Customizing documen-
mat/medium/channel dium/channel is sest for an order
tation
that is created through the UI.
• Determining For-
As a result, you can create different mat/Medium/Channel
Fiori tiles for different format/me- by Reconciliation Units
dium/channel combinations. [page 383]

When searching for the correct for-

mat/medium/channel combination,
the system checks the following Cus-
tomizing table entries in the following
sequence:

1. Payment Engine File

Handler Basic Settings

Maintain Converter
2. Depending on whether the pay-
ment is at order or at item level:

• Payment Engine UI

Map Default Values to

Metaformat for Payment

Orders

• Payment Engine UI

Map Default Values to

Metaformat for Payment

Items

3. Payment Engine

Reconciliation Assign
Reconciliation Units to Converter

Attributes

As soon as a format/medium/chan-
nel combination is found, the search
stops (That is, only if no combination
is found in the first table, does the
system check in the second table,
and so on.

Payment Engine (FS-PE)

What’s New in SAP Payment Engine 9.0 PUBLIC 83
Function Type of Change Description More Information

EPC inbound converter New New EPC inbound converters for cus- The message types for the
tomer initiated payments have been relevant converters are as
implemented. follows:

• /
EPC_CT_R17_PAIN.00
1.001.03 EPC Cus-
tomer Credit Transfer In-
itiation - Rulebook 2017
• /
EPC_CORE_R17_PAIN.
008.001.02 EPC Core
Customer Direct Debit
Initiation - Rulebook
2017
• /
EPC_B2B_R17_PAIN.0
08.001.02 EPC B2B
Customer Direct Debit
Initiation - Rulebook
2017

GBIC inbound converter New New GBIC inbound converters for The message types for the
customer initiated payments have relevant converters are as
been implemented. They follow ver- follows:
sion 3.1 of the rulebook published by
• /
the German Banking Industry Com-
DK_CT_R17_PAIN.001
mittee.
.001.03 Customer
Credit Transfer DK 3.1
- 2017
• /
DK_DD_R17_PAIN.008
.001.02 Customer Di-
rect Debit DK 3.1 –
2017
• /
DK_CAMT.055.001.05
Customer Payment
Cancellation Re-
quest - DK 3.1 – 2017
• /
DK_R17_CONTAINER.N
NN.001.02 Container
DK 3.1 - 2017

Payment Engine (FS-PE)

84 PUBLIC What’s New in SAP Payment Engine 9.0
Function Type of Change Description More Information

Bundesbank cheque direc- New The upload report for referential data In transaction /PE1/
tory has been extended by the cheque di- UPLOAD_RD choose data
rectory of the German Bundesbank. model CHQ and data provider
BUB to import the Bundes-
bank cheque directory.

2.11 Changes and New Features in SAP Payment Engine 9.0

SP01

This table provides an overview of changes and new features that have been introduced in SAP Payment Engine
9.0, SP01.

Function Type of Change Description More Information

Recall Changed The following attrib-

utes have been
added:

• From ... To ... (in

addition to the
existing To ...)
• Cheque ID

Liquidity management New You can connect SAP Connection to a Liquidity Management System
Payment Engine to a [page 171]
liquidity management
system through a
proxy.

Account Property New The Account Property

attribute is available.

Product New For rule sets, the new

attribute Product is
available.

Payment Engine (FS-PE)

What’s New in SAP Payment Engine 9.0 PUBLIC 85
Charges - Differentia- Changed In addition to the ex- Charges [page 192]
tion Categories isting differentiation
categories, the follow-
ing new differentiation
categories are availa-
ble:

• D30 - Product
• D31 - Product
Group
• D32 - Instruction
Code
• D33 - Currency
Group
• D34 - Coun-
try Group (Recip-
ient)
• D35 - Country
(Recipient)
• D36 - Account
Type

Charges - Event- Changed Event-driven charges Charges [page 192]

Driven Charges are no longer man-
aged separately. Now
both transaction
charges and event-
driven charges are
managed by charge
processes.

Clearing Agreement - Changed Charges are no lon- Charges [page 192]

Charges ger managed under
a clearing agreement.
Charges are now
managed under a
service level agree-
ment.

Routing Changed In addition to the ex-

isting categories for
determining a clearing
route, a certain per-
centage of payment
items can now be
directed to another
clearing route.

Payment Engine (FS-PE)

86 PUBLIC What’s New in SAP Payment Engine 9.0
Value date agreement Changed The calendars of all Value Date Agreement [page 244]
involved countries of
an FX transaction can
be considered to cal-
culate the value date
agreement.

Service level agree- Changed A new hierarchy level Service Level Agreement [page 256]
ment (SLA) has been introduced:
The customer group
SLA is available as a
new type of SLA.

The field currency has New The conditions and Service Level Agreement [page 256]
been added to SLA restrictions that apply
conditions to SLAs can now also
include a currency
check.

SLA, foreign exchange Changed A new tab page is Service Level Agreement [page 256]
(FX) available for FX. The
existing fields have
been moved to this
tab. In addition, you
can use the following
rules sets to allow
flexible control of FX
transactions:

• FX Account
Substitution
• FX Rate
Adjustment
You can now de-
fine a spread fac-
tor (instead of
percentage) in
the rule set.
• FX Country
Equivalent

These new functions

replace the existing
conversion mainte-
nance. You can mi-
grate the existing cur-
rency exchange table
by using report /PE1/
R_MIGRATION_FX_S
LA to the new rule
sets.

Payment Engine (FS-PE)

What’s New in SAP Payment Engine 9.0 PUBLIC 87
SLA, correspondence Changed A new tab page is Service Level Agreement [page 256]
available to define
correspondence set-
tings for SLAs. A new
rule set is available to
flexibly control corre-
spondence.

SLA determination New The system can deter- Service Level Agreement [page 256]
based on business mine the relevant SLA
partner (BP) IDs also based on busi-
ness partner IDs. To
identify the relevant
customer SLA, cus-
tomer group SLA, and
customer segment
SLA , the system uses
the BP ID (from SAP
Business Partner). If
no BP is found, the
system uses the exist-
ing account informa-
tion. This reduces the
effort for maintaining
accounts in the SLA.

Converter Changed The following formats File Handler (FS-PE-FH) [page 289]
have been added to
the converters:

• DTAZV (inbound
only)
• Eurogiro

New separation crite- New When you set up col- Setting Up Queues and Collectors [page 342]
lectors, you can now
rion Eurogiro for col-
also use the Eurogiro
lections
product code and the
charge category as a
separation criteria.

New Eurogiro format New The Eurogiro now Eurogiro [page 305]
supports format
MT910 in the incom-
ing channel.

Payment Engine (FS-PE)

88 PUBLIC What’s New in SAP Payment Engine 9.0
Clearing account Changed In addition to the ex- Service Level Agreement [page 256]
isting bank file clear-
ing, a clearing ac-
count can now also
be determined via the
business partner in an
SLA.

Payment Engine (FS-PE)

What’s New in SAP Payment Engine 9.0 PUBLIC 89
Enrichment and vali- New New enrichment and Enrichment and Validation (FS-PE-EV) [page 311]
dation validation checks
Configurable Correspondence Types: Correspond-
have been added:
ence (FS-PE-COR) [page 410]
• Admissibility of
Business Partners: Service Level Agreement
Codewords and
[page 256]
Instruction Keys
• STP Capability
• Configurable
Correspondence
Types
• Business Part-
ners
• Duplicate Sub-
mission
• Risc Score
• Crisis
• Account Number
Format
• Route Simulation
• Cut-Off Time
• SWIT Tags
(cross check of
fiels 53, 54, 55,
56, 57, and 58)
• Priority Attribute
for Foreign Cur-
rency Trade Re-
porting
• Right of disposal:
If the sender of
the transaction
message is differ-
ent from the ac-
count holder, the
system checks if
the sender has a
right of disposal
for the clearing
account.
You can use the
Customizing ac-
tivity Maintain
Check Rules for
Business Partner
Relationships to

Payment Engine (FS-PE)

90 PUBLIC What’s New in SAP Payment Engine 9.0
 define the right
of disposal
in Customizing
for Payment
Engine under

Payment Item

Payment Item
Enrichment and

Validation .

Embargo check in out- New The embargo check Embargo Check [page 333]
going E&V check can now be config-
ured for incoming or
outgoing enrichment
and validation (E&V)
check sets.

SAP Fiori apps New The following SAP User Interface [page 372]
Fiori apps are availa-
ble:

• Create Payment
• Manage
Payments
• Manage Waiting
Payments
• Repair Payments
• Manage Payment
Blocks
• Foreign Exchange
Trade Reporting
• Release (My
Inbox)

UI enhancements for New Rate calculation fea- Foreign Exchange Rates [page 122]
rate calculation tures within foreign
payment transactions
have been enhanced

Reservation mecha- New You can now re- Repair Payments (SAP Fiori) [page 387]
serve payment or-
nism in Repair
ders and payment
Payments app
items displayed in
the Repair Payment
app. Orders/items re-
served by you cannot
be processed by oth-
ers, unless they ac-
tively remove the res-
ervation.

Payment Engine (FS-PE)

What’s New in SAP Payment Engine 9.0 PUBLIC 91
Reservation mecha- New You can now reserve Release [page 393]
work itemsin the mas-
nism in Release My
ter/detail variant of
Inbox app
the release app. You
can also configure the
settings of the expert
mode variant in such
a way that accessing
the detail screen of
a work item automati-
cally reserves the item
for the user.

Correspondence New You can use the

types following new corre-
spondence types:

• PO Processing
Confirmation
• Confirmation
Settlement
Completed
• Liquidity Advice
• PO Non-
Execution
Confirmation
(MT101
Fehleravis)
• Automatic
Country Currency
Conversion

You can activate

them in Customizing
for Cross-Application
Components under

General Application

Functions Define
Correspondence

Types and Define

Application Forms for
Correspondence.

Payment Engine (FS-PE)

92 PUBLIC What’s New in SAP Payment Engine 9.0
Customizing New The following new ac- See Customizing documentation

tivities or nodes have

been added in Cus-
tomizing for Payment
Engine:

• UI
• Maintenance
Exception
Handling
Errors to be
ignored
• Developmen
t
• Country Specific
Settings
• Maintain
Country-
Specific
Processing
Attributes
• Germany
• Basic Settings
• Local
System
Managemen
t System
• Product
Definition
• Charges
• Assign
Conditio
n Types
to
Product
s
• Determi
ne Item
Charge
Amount
Limits
• Determi
ne
Trivial
Minimu
m
Limits

Payment Engine (FS-PE)

What’s New in SAP Payment Engine 9.0 PUBLIC 93
 • Foreign
Exchange
• Request Agent

• Referential

Data Release
of Embargo/

Crisis
• File Handler
• File Handler
Exception
Handling

• SWIFT
Format

Converter
Determine
External
Charge
Informatio

n
• Eurogiro
Envelope
Format
Converter

• XML Converter

Generic
Mapping Based

on Tag Paths

• Payment

Order SLA

Assign Account
Product to
Customer

Segment

• Payment

Order Payment
Order Enrichment
and Validation

Check Specific

Configuration
• Maintain
Rules for
Risk Scoring

Payment Engine (FS-PE)

94 PUBLIC What’s New in SAP Payment Engine 9.0
 • Maintain
Rules for
Liquidity
Process
• Error Rate
Check

• Payment Item

Payment Item
Enrichment and

Validation
• Maintain
Currency
Groups
• Maintain
Country
Groups
• Maintain
Check Rules
for Business
Partner
Relationship
s
• Define
Custom
Code for
Country

• Field
Validation
and Routines

Account
Routine and
E&V
Conversio

n
• STP
Relevance

• Routing
Control

Business Add-Ins

(BAdIs)
• Determinatio
n of Next
Institution

Payment Engine (FS-PE)

What’s New in SAP Payment Engine 9.0 PUBLIC 95
 • Clearing
System
Identification
• Clearing
• Maintain
Rules for
Posting
Simulation
• Maintain
Rules for
Reservation
Process
• Configuratio
n for
Processes
• Define
Process
Symbol
• Maintai
n
Process
-Depen
dent
Account
s

• Posting
Interfaces

Account
Management

Systems PE

Account Type

• Exception

Control Define
Response Types

Response
Types: Payment

Order
• Define
Reaction
Types for
Outgoing
Order -
Failed Item
processing

Payment Engine (FS-PE)

96 PUBLIC What’s New in SAP Payment Engine 9.0
 • Define
Response
Types for
Release
Workflow

• Exception

Control Define
Response Types

Response
Types:
Payment Item

Reactions
for Outgoing

Processes
Define Response
Type to
Exclude Items
from Outgoing

Orders

• Tools

Correspondence

Assign
Correspondence
Synchronization

Type

Payment Engine (FS-PE)

What’s New in SAP Payment Engine 9.0 PUBLIC 97
3 End-to-End Payment Processing

Use

This process covers the payment processing workflow in Payment Engine: from importing payment transaction
data, to fully automated straight-through processing (STP) in the Payment Processing, Routing Control, and
Clearing Processing components, through to exporting external payment items for forwarding to an account
management system.

STP stops only if errors occur during enrichment and validation and route processing that the system cannot
handle automatically. In this case, the system sends exceptions to Exception Control. Exception handling is
semi-automated; therefore, as soon as an error has been corrected, STP is resumed.

 Note

This process is also relevant to cross-border payment processing; however, it does not include the process
steps that are specific to cross-border payments. For more information, see Basic Cross-Border STP [page
101].

Process

The following steps give an example of a typical payment processing scenario:

1. When a financial institution receives a payment file from a customer, a periodic job or monitoring function
in the file-management software recognizes that there is a new file to be sent to Payment Engine.
For more information, see File Handler (FS-PE-FH) [page 289].
2. Based on the information in the file, such as channel, medium, format, path, and file name, the Input
Manager recognizes and selects the correct format converter. The format converter reads the file, maps
the input format to the Payment Engine metaformat, and stores the payment order in the Payment Engine
database.

 Note

Any information or fields in the original payment order that are not required for processing in Payment
Engine can be stored in the File Handler Database. This ensures that the Output Manager still has all
the original data available in case information about the incoming payment order is to be placed in an
outgoing order after processing.

For more information, see File Handler Database [page 297] and Input Manager [page 291].
3. The system checks the payment order in terms of formal and referential accuracy, material errors, and
consistency. If required, the system enriches the payment information.
For more information, see Payment Processing (FS-PE-POP) [page 309] and Enrichment and Validation
[page 311].
4. The system sends the ordering party item (the debit side of a credit transfer) to route processing, where a
route is determined. This route is always internal. It can lead directly to the internal account management

Payment Engine (FS-PE)

98 PUBLIC End-to-End Payment Processing
 system where the account of the ordering party is managed or it can lead first to an application that
performs a credit-limit check.
The credit-limit check authorizes the payment based on the limit or the current amount available in the
account of the ordering party. The requested amount is reserved, pending authorization. If the payment is
authorized, Payment Engine forwards a reservation request to the account management system.
5. The system releases the payment order for processing (after successful authorization of the ordering
party) and transfers the recipient items (the credit side of a credit transfer) of the payment order to route
processing.
The system determines the route, the associated clearing agreement, and the value date agreement for
each recipient item.
For more information, see Routing Control (FS-PE-RP) [page 205].
6. The system transfers the recipient items to clearing and settlement, enriched with a reference to the
routes, the clearing agreements, and the value date agreements.
The system uses the route and clearing agreement information to determine how the recipient items
should be further processed.
For more information, see Clearing Processing (FS-PE-CP) [page 337].
7. If a reservation request was sent for the ordering party item and all recipient items have been successfully
posted, the reservation is changed to a posting request.
This completes processing of the incoming payment order in Payment Engine.
8. If the system placed recipient items in collectors to be forwarded as part of a batch, it monitors these
collectors. It determines whether any of items fulfill the closing criteria, such as the maximum number of
items and maximum total amount.

 Note

The system constantly checks and updates the collectors by an independent process, separate from
the primary process. The system also checks whether collectors need to be closed when a certain time
limit is reached.

9. When a collector is closed, the system generates a clearing item (collector total) and routes the clearing
item to the account management system that contains the clearing account (a nostro or vostro account)
for posting.

 Note

From this step, incoming payment orders can be finalized and final correspondence can be triggered.
An incoming payment order is finalized when all payment items are finalized, that is, posted or
assigned to an outgoing payment order and incoming processing is completed.

10. The system creates a new outgoing payment order that contains all payment items in the clearing collector
and forwards the outgoing payment order from Clearing Processing to Output Manager in the Payment
Engine metaformat.
11. Output Manager recognizes the correct format converter from the channel, medium, and target format
information included in the outgoing payment order and maps the outgoing metaformat to the target
format.

 Note

All information and fields of the original payment order are available during mapping (partially read
from the File Handler Database by the format converter and partially derived from the outgoing
payment order in metaformat). Additionally, the system performs format-dependent checks on the
outgoing payment order in the format converter.

Payment Engine (FS-PE)

End-to-End Payment Processing PUBLIC 99
 For more information, see Output Manager [page 295].
12. Output Manager transfers the payment order to the relevant outgoing channel in the target format.

Payment Engine (FS-PE)

100 PUBLIC End-to-End Payment Processing
4 Basic Cross-Border STP

Use

You can use this process in the context of end-to-end processing of cross-border payments to:

• Validate incoming payment orders in the form of SWIFT message type MT103+
• Determine the payment transaction chain
• Calculate charges
• Route payments to the next financial institution in the transaction chain
• Perform clearing and settlement

Prerequisites

• You have defined the checks run during enrichment and validation and checked the settings of checks
specific to cross-border payment processing in Customizing for Payment Engine under:
• Payment Order Payment Order Enrichment & Validation Maintain Enrichment & Validation Check
Set Rules
• Payment Order Payment Order Enrichment & Validation Maintain Enrichment & Validation
Checks
• Payment Order Payment Order Enrichment & Validation Maintain Enrichment & Validation Sets
for Order Types
• Payment Items Maintain Enrichment and Validation Set for Payment Items
• Payment Items Transaction Types and Transaction Type Groups
• You have managed service level agreements on the SAP Easy Access screen by choosing
Payment Engine Master Data Service Level Agreements Manage Service Level Agreement
(transaction /PE1/SLA). For more information, see Service Level Agreement [page 256] and Managing
Service Level Agreements [page 260].
• You have assigned charges to service level agreements and clearing agreements. For more information, see
Charges [page 192].
• You have uploaded and managed standard settlement instructions. For more information, see Upload of
Referential Data (SSI) [page 178].

Process

1. You upload a payment order to the system over the Payment Order Interface of SWIFT message type
MT103+.

Payment Engine (FS-PE)

Basic Cross-Border STP PUBLIC 101
2. The system converts the MT103+ message to the Payment Engine metaformat.
3. To ensure that the information in the MT103+ message is mapped to the Payment Engine metaformat
correctly, the system performs the enrichment and validation process.

Enrichment and Validation

1. The system reads the payment order.

2. The system determines the transaction chain based on the ordering BIC, the beneficiary BIC, and the
transaction currency.
If Payment Engine is the first institution in the transaction chain, the system enriches the transaction
chain of the payment; otherwise, the incoming SWIFT message already contains the transaction chain and
the converter fills the fields. For more information about the determination of the transaction chain, see
Standard Settlement Instructions (SSI) [page 176].
3. If the ordering institution and the beneficiary institution have a direct account relationship, only two BICs
are returned, that is, the first institution and the last institution in the transaction chain; otherwise, the
intermediary institution(s) are also returned.

 Note

If the return structure is empty, the two institutions are not able to exchange messages. In this case,
the enrichment and validation check was not successful and exception handling is triggered. For more
information about exception handling, see Exception Control (FS-PE-EH) [page 265].

4. The system calculates the charges for the customers in the payment transaction.
To determine the correct charge amount, it checks the:
• Charge condition group
• Bank identifier code (BIC)

 Note

If the charge has to be determined for the ordering party item, the BIC of the beneficiary is
relevant. If the charge for the recipient item has to be determined, the BIC of the ordering party
institution (reference account data of the recipient item) is relevant.

• Charge category
• Transaction currency
• Transaction amount
• Validity date
5. The system retrieves the charge amount from the charge catalog, which is currently stored in the Financial
Conditions component. For more information, see Charges [page 192].

 Note

If a charge provider other than Financial Conditions is used to handle charges, you must implement an
additional enrichment and validation check. In Customizing, you implement a method to calculate the
charges for a payment transaction based for the specific charge provider.

6. The system validates the charges that are sent from the previous bank in an MT103+ message.

 Note

This check is only necessary for the charge category OUR and when the financial institution running
Payment Engine is not the first financial institution in the transaction chain.

Payment Engine (FS-PE)

102 PUBLIC Basic Cross-Border STP
  Note

If the charges are not correct, exception handling is triggered.

For more information about enrichment and validation checks, see Enrichment and Validation Checking [page
315].

Route Processing

1. The system determines the route and the clearing agreement.

 Note

The system uses the receiver BIC of the next message defined in the rule sets of routes and clearing
agreements to determine the route and the clearing agreement

2. The system routes the payment item to the beneficiary and to an intermediary institution in the
transaction chain.

For more information about the routing process, see Routing Control (FS-PE-RP) [page 205].

Clearing and Settlement

1. The system determines the bilateral agreed charges that have to be sent to the direct correspondent
institution by retrieving the charge condition group from the clearing agreement.
2. The system uses the charge condition group to determine the charges defined in the charge catalog.
3. In a BEN scenario, the system reduces the settled amount by adding the charges to be debited to the
clearing item. It therefore also reduces the amount of the recipient item by subtracting the charge accrued
for the ordering party item from the transaction amount.

 Note

Any change to the original amount is logged in an application log.

4. In an OUR scenario, the system increases the amount by adding the charges to be credited, which are
bilaterally agreed on by two financial institutions, before finally posting the clearing item.

More Information

Cross-Border Payment Processing [page 103]

4.1 Cross-Border Payment Processing

Concept

Payment Engine provides functions that support end-to-end processing of cross-border payments, including
the upload and management of referential data, handling of payment transaction charges, and fully automated
straight-through processing (STP).

Payment Engine (FS-PE)

Basic Cross-Border STP PUBLIC 103
These functions support payment processing in the context of international payments. For more information
about end-to-end processing of domestic payments, see End-to-End Payment Processing [page 98].

Payment Engine currently supports:

• Conversion and processing of SWIFT MT103+ messages (Single Customer Credit Transfer)
• Automated straight-through processing (STP)
• Determination of correspondence banks by means of standard settlement instructions (SSI) provided by
Accuity/CB.Net.

Features

The following features support processing of cross-border payments.

Referential Data

• Upload, validation, and management of referential data required for routing, validation, and clearing
• Enrichment of data based on standard settlement instructions (SSI) to support routing of international
payments

For more information, see Referential Data Interface (FS-PE-RDI) [page 172] and Standard Settlement
Instructions (SSI) [page 176].

Processing of Charge Information

• Management of payment transaction charges for customers and financial institutions in the corresponding
service level agreements (SLA) and clearing agreements
• Calculation and validation of payment transaction charges
• Posting of payment transaction charges to an account management system
• Posting of charges to a customer account

For more information, see Charges [page 192].

Straight-Through Processing

• Enrichment and validation

• Enrichment and validation checks to support cross-border payment processing
• Calculation and validation of payment transaction charges
• Determination of the payment transaction chain of a payment order
• Route processing
Routing of a payment item not only to the beneficiary but also to an intermediary institution in the
transaction chain

 Note

The route ruleset supports routing rules that specify the bank identifier code (BIC) of the next
institution (receiver) in the transaction chain.

• Clearing and settlement

• Posting of charges to a customer account. The settled amount is adapted to the accrued charges.
• Calculation of payment transaction charges based on charge condition groups in the clearing
agreement

Payment Engine (FS-PE)

104 PUBLIC Basic Cross-Border STP
For more information, see Basic Cross-Border STP [page 101].

Payment Engine (FS-PE)

Basic Cross-Border STP PUBLIC 105
5 Payment Processes

Use

Payment Engine supports the following payment processes:

• Request for cancellation

• Recall of SEPA credit transfers
• Cash pooling with request for transfer
• Foreign Exchange (FX)

More Information

• Request for Cancellation [page 106]

• Recall of SEPA Credit Transfers [page 113]
• Cash Pooling with Request for Transfer [page 121]
• Foreign Exchange (FX) [page 284]

5.1 Request for Cancellation

Use

Request for cancellation is a process requirement for SEPA Direct Debits (SDD) and SEPA Credit Transfers
(SCT). For example, customers who initiate SDDs can cancel payment transactions up until the due date. For
this purpose, the creditor bank sends a request for cancellation prior to settlement in order to recall a previous
payment instruction. The debtor bank has to accept the request for cancellation from the creditor bank by due
date.

Payment Engine supports the following scenarios:

• Active request for cancellation

• A recall is created out of customer call. If an outgoing message for the external payment items has
already been sent, a payment cancellation request (camt.056) message must be created.
• A recall is created for an SDD or an SCT by importing a customer payment cancellation request
(camt.055) message.
• Passive request for cancellation
A recall is created out of an interbank message (camt.056). No further message must be created.

Payment Engine (FS-PE)

106 PUBLIC Payment Processes
Implementation Considerations

The SEPA Core Direct Debit Scheme Rulebook developed by the European Payments Council (EPC) does
not cover requests for cancellation. The process for requesting for payment cancellation forms is part of
the bilateral agreement between the creditor bank and the clearing house, also known as the clearing
settlement mechanism (CSM). However, it is mandatory that financial institutions that operate a Euro Banking
Association’s (EBA) clearing system can handle requests for cancellation.

 Note

The functions and processes implemented in the Account Management (AM) Proxy component are
designed for communication with the SAP Deposits Management and Bank Customer Accounts (BCA)
account management systems.

Features

• Conversion of incoming Payment Cancellation Requests messages (camt.056/camt.055) in the Input

Manager and outgoing Payment Cancellation Request messages (SDD camt.056) in the Output Manager
or via Request Agent (SCT camt.056). For more information about converters, see File Handler (FS-PE-
FH) [page 289].
• Initiation of requests for cancellation in the File Handler or through the creation of a recall in Exception
Control. For more information about recalls, see Recall Management [page 144].
• Communication with the account management system to which the payment to be canceled has been
forward over the Account Management Proxy. The system calls the return or posting functionality. For
more information, see Connection to an Account Management System [page 166].
• Initiation of the BAPI return functionality implemented in Item Management in the Account Management
(FS-AM) component.
• Interaction between File Handler and Clearing Processing to initiate posting to the account management
system. For more information about clearing and settlement, see Clearing Processing (FS-PE-CP) [page
337].
• Collection of payment items for outgoing Requests for Cancellation by the same original message ID for
forwarding one outgoing file to a clearing house. For more information about collection separation criteria,
see Clearing Agreement [page 219] and Setting Up Queues and Collectors [page 342].

More Information

Active Request for Cancellation [page 108]

Passive Request for Cancellation [page 111]

Payment Engine (FS-PE)

Payment Processes PUBLIC 107
5.1.1 Active Request for Cancellation

Use

You can use this process to return external payments or stop external payment transactions.

Prerequisites

• You have mapped external return reasons, that is, the return reasons used by the external system of
the creditor bank or other financial institution that initiated the return, to return reasons defined in
Payment Engine in Customizing for Payment Engine by choosing File Handler Process Integration
Format Converter Map External Return Reasons to PE Return Reasons .
• You have specified the R-transaction of the original transaction type and mapped the original transaction
type to the transaction type to be used for the target item in Customizing for Payment Engine by choosing
File Handler Process Integration Format Converter Define Transaction Types for R-Transaction
Types .
• You have defined the time range for a specific recall type and recall group and whether payment items with
a final status can be processed in Customizing for Payment Engine by choosing Recall Management
Maintain Valid-To Date .
• You have defined response types for external returns in Customizing for Payment Engine by choosing
Exception Control Define Response Types Response Types: Payment Item Define Response Types
to Trigger External Returns .
• You have determined how Payment Engine responds to return messages sent from an account
management system in Customizing for Payment Engine by choosing Posting Interfaces DM Proxy
[or] BCA Proxy Return Determine Responses to AM Return Messages .
• You have mapped the return reasons defined in Payment Engine to the return reasons defined in the
connected account management system in Customizing for Payment Engine by choosing Posting
Interfaces DM Proxy [or] BCA Proxy Return Map PE Return Reasons to AM Return Reasons .
• You define the payment item category to which a payment item is converted for posting to an account
management system in Customizing for Payment Engine by choosing Posting Interfaces DM Proxy [or]
BCA Proxy Posting Determine Payment Item Category for Posting .

Process

a) The following process is an example of the process for an active request for cancellation with external
payment items. The creditor of a SEPA Direct Debit (SDD) calls the creditor bank to request cancellation of the
SDD to return or stop the execution of the SDD. The outgoing message has already been sent.

1. You create a recall for the payment order or for at least one payment item of the payment order.
You create a recall manually for a payment order or a payment item by using BAPI /PE1/
BAPI_RECALL_CREATE. The recall is assigned to the recall group for request for cancellation. To return

Payment Engine (FS-PE)

108 PUBLIC Payment Processes
 an entire payment order, you must create a recall for each recipient item manually. For more information
about creating recalls, see Recall Management [page 144].

 Note

You cannot recall a payment order if the ordering party item has already been posted to
the account management system. However, if the due date has not been reached, BAPI /PE1/
BAPI_RECALL_ACTIVATE sends the recall information and the payment order ID to the account
management system. The system recalls all payment items assigned to this payment order when the
status of payment items for future posting is updated.

2. The recall identifies the matching payment order or payment items if the item status is final (status 31
(Posted in Account Management System) or status 29 (Item in Future Posted in AM), but the posting date
has not been reached.
3. In Exception Control, the system creates a new payment order with one ordering party item and one
recipient item.

 Note

Exception Control supports a response type for the recall of internal payment items. For more
information about response types, see Response Type [page 269].

4. The system posts both the ordering party item and the recipient item as recipient items so that they are
returnable in the account management system.
5. The system posts the payment items to the account management system over the Account Management
Proxy. For more information about communication with the account management system, see Connection
to an Account Management System [page 166].
6. The account management system uses the reference account information to create the payment items
and sends the items back to Payment Engine over the Outgoing Payment Dispatcher (OPD).
7. The system creates two new payment orders in the Process Integration (XI) converter:
• A payment order that returns the amount from the customer account
• A payment order that creates a camt.056 message using the corresponding outgoing converter
8. The system posts the clearing item as a payment item for future posting to the account management
system and sends an outgoing camt.056.001.01 message to the clearing house.

b) The following process is an example of the process for an active request for cancellation with external
payment when the creditor of a SEPA Direct Debit (SDD) sends a camt.055 message to the creditor bank to
request cancellation of the SDD to return or stop the execution of the SDD. The outgoing message has already
been sent.

1. You create a recall for the payment order or for at least one payment item of the payment order.
The camt.055 message is imported in the Input Manager. The recalls are created and assigned to the recall
group for Electronic recalls. For each recall also a request agent is created with status 20 (Triggered). The
camt.055 message is sent either on payment order level or on payment item level.

 Note

You cannot recall a payment order if the ordering party item has already been posted to
the account management system. However, if the due date has not been reached, BAPI /PE1/
BAPI_RECALL_ACTIVATE sends the recall information and the payment order ID to the account
management system. The system recalls all payment items assigned to this payment order when
the status of payment items for future posting is updated.

Payment Engine (FS-PE)

Payment Processes PUBLIC 109
2. The recall identifies the matching payment order or payment items if the item status is final (status 31
posted in Account Management System) or status 29 (Item in Future Posted in AM), but the posting date
has not been reached.
3. In Exception Control, the system creates a new payment order with one ordering party item and one
recipient item.

 Note

Exception Control supports a response type for the recall of internal payment items. For more
information about response types, see Response Type [page 269].

4. The system posts both the ordering party item and the recipient item as recipient items so that they are
returnable in the account management system.
5. The system posts the payment items to the account management system over the Account Management
Proxy. For more information about communication with the account management system, see Connection
to an Account Management System [page 166].
6. The account management system uses the reference account information to create the payment items
and sends the items back to Payment Engine over the Outgoing Payment Dispatcher (OPD).
7. The system creates two new payment orders in the Process Integration (XI) converter:
• A payment order that returns the amount from the customer account
• A payment order that creates a camt.056 message using the corresponding outgoing converter
8. The system posts the clearing item as a payment item for future posting to the account management
system and sends an outgoing camt.056.001.01 message to the clearing house.
9. The status of the request agent is set to 30 (Feedback Received) after the confirmation of the ordering
party items is received from the account management system.
10. An outgoing camt.029 message is sent to the customer with a positive response (Confirmation status
CNCL – CancelledAsPerRequest) via the request agent. (From the SAP Easy Access menu, you choose
Payment Engine Periodic Processing Processes Request Agent Mass Processing to schedule this in
end-of-day processing with the action Process.)
11. If no payment order or payment items are identified by the recall, the status of the request agent is set to
22 (To be Forwarded) and an outgoing camt.029 message is sent to the customer with confirmation status
UWFW – UnableToApplyWillFollow via the Request Agent Mass Processing Run with the action Forward.
12. If a matched payment order or payment items arrive later on, in case of a payment order, it is rejected
and the status of the request agent is set to 30 (Feedback Received) and the Feedback field to 0001
(Accepted). In case of a payment item, the system must clear only posted ordering party items, and does
so by redirecting them to a CpD account. Once the ordering party item has been cleared in the account
management system and received in FS-PE, the system sets the request agent status to 30 (Feedback
Received) and the Feedback field to 0001 (Accepted). An outgoing camt.029 message is sent to the
customer with a positive response (confirmation status CNCL – CancelledAsPerRequest) via the request
agent. (From the SAP Easy Access menu, you choose Payment Engine Periodic Processing Processes
Request Agent Mass Processing to schedule this in end-of-day processing with the action Process.)
13. If no payment order or payments items are matched within 25 bank working days, the status of the request
agent is set to 30 (Feedback Received) and the Feedback field to 0003 (Expired) via the Request Agent
Mass Processing Run with the action Expire. An outgoing camt.029 message is sent to the customer with
confirmation status RJCR – Rejectedvia the Request Agent Mass Processing Run with the action Process.

Payment Engine (FS-PE)

110 PUBLIC Payment Processes
More Information

Request for Cancellation [page 106]

Passive Request for Cancellation [page 111]

5.1.2 Passive Request for Cancellation

Use

You can use this process to return internal payment items that have been posted to a connected account
management system.

Prerequisites

• You have mapped the return reasons used by the external system of the creditor bank or other financial
institution that initiated the return to return reasons defined in Payment Engine. To do this, in Customizing
for Payment Engine choose File Handler Process Integration Format Converter Map External Return
Reasons to PE Return Reasons .
• You have specified the R-transaction of the original transaction type and mapped the original transaction
type to the transaction type to be used for the target item. To do this, in Customizing for Payment
Engine choose File Handler Process Integration Format Converter Define Transaction Types for R-
Transaction Types .
• You have defined the time range for a specific recall type and recall group and whether payment items with
a final status can be processed in Customizing for Payment Engine by choosing Recall Management
Maintain Valid-To Date .
• You have defined response types for internal returns in Customizing for Payment Engine by choosing
Exception Control Define Response Types Response Types: Payment Item Define Response Types
to Trigger Internal Returns .
• You have determined how Payment Engine responds to return messages sent from an account
management system in Customizing for Payment Engine by choosing Posting Interfaces DM Proxy
[or] BCA Proxy Return Determine Responses to AM Return Messages .
• You have mapped the return reasons defined in Payment Engine to the return reasons defined in the
connected account management system in Customizing for Payment Engine by choosing Posting
Interfaces DM Proxy [or] BCA Proxy Return Map PE Return Reasons to AM Return Reasons .

Payment Engine (FS-PE)

Payment Processes PUBLIC 111
Process

The following process is an example of the process for a passive request for cancellation with internal payment
items when a clearing house, for example, the EBA Clearing, forwards an interbank message (a camt.056
message) to the debtor bank.

1. The Input Manager receives a camt.056 message. For more information about the Input Manager, see
Input Manager [page 291].
2. The inbound converter converts the camt.056 message to the internal metaformat for a bank item recall
and forwards it to Exception Control. For more information about converters, see File Handler (FS-PE-FH)
[page 289].

 Note

Exception Control supports a response type for the recall of internal payment items. For more
information about response types, see Response Type [page 269].

3. The recall searches for recipient items that do not have a posting date in the past. For more information
about the recall matching process, see Recall Processing [page 147].

 Note

The recipient items can already have a final status because the posting date does not need to be sent
to the account management system.

4. The system returns the corresponding item to the account management system over the Account
Management Proxy. For more information about communication with the account management system,
see Connection to an Account Management System [page 166].
5. A payment item is created in the account management system as a result of the return.
6. The account management system sends the payment item back to Payment Engine over the Outgoing
Payment Dispatcher (OPD).
7. The system creates a new payment order in the Process Integration (XI) converter:
• The amount of the ordering party item is posted to the OPD account.
• The recipient item finds an external route and a clearing agreement for a “dummy converter”. For more
information about routing, see Routing Control (FS-PE-RP) [page 205].
8. The system posts a clearing item to the clearing account of the clearing house.

More Information

Request for Cancellation [page 106]

Active Request for Cancellation [page 108]

Payment Engine (FS-PE)

112 PUBLIC Payment Processes
5.2 Recall of SEPA Credit Transfers

Definition

The recall of a SEPA credit transfer (SCT) takes place when the originator bank requests the cancellation of a
SEPA credit transfer.

According to the SEPA Credit Transfer Rulebook, version 4.0, a bank can recall a SEPA credit transfer if it is a
duplicate, technically incorrect, or has been triggered with fraudulent intent.

An SCT recall has the same route as the original SEPA credit transfer (no change to the original data), and
recall payment messages contain a reason code.

The following SEPA payment transaction formats are used in this process:

• camt.056 (recall of credit transfer)

• camt.029 (result of investigation)
• pacs.008 (original credit transfer)
• pacs.002S2 (payment cancellation file)
• pacs.004 (credit transfer can be recalled)

Within 10 bank working days of the settlement of the SEPA credit transfer, the originator bank can initiate a
recall by sending a request for recall (camt.056).

For passive recalls, it is also possible to route the recall through a third-party financial institute such as a
clearing house.

If the payment item has been transferred to the clearing house but yet to be settled, the clearing house
discontinues the transaction and returns a cancellation report (pacs.002S2).

If the SCT can be processed at the beneficiary bank a message (pacs.004) is generated. If the SCT cannot be
processed, a result of investigation message (camt.029) is generated.

Payment Engine (FS-PE) enables both the originator bank and the beneficiary bank of a SEPA credit transfer to
map this process.

More Information

For more information about this process in the system at the originator bank, see Active Recall of SEPA Credit
Transfers [page 114].

For more information about the process in the system at the beneficiary bank, see Passive Recall of SEPA
Credit Transfers [page 118].

For more information about recalls, see Recall [page 142].

For more information about routing recalls through third-party financial institutes, see Customizing for
Payment Engine (FS-PE), under:

• Basic Settings Organization Assign BIC to Clearing Area and Contract Partner

Payment Engine (FS-PE)

Payment Processes PUBLIC 113
• Request Agent Determine Routing for Third-Party CAMT Messages .
• Request Agent Business Add-Ins (BAdIs)

5.2.1 Active Recall of SEPA Credit Transfers

Use

The active recall of SEPA credit transfers (SCT) describes what happens at the originator bank when an SCT
recall takes place.

Prerequisites

• The SEPA credit transfer is a duplicate, technically incorrect, or has been triggered with fraudulent intent.
• The originator bank triggers the recall within 10 bank working days of the settlement of the SEPA credit
transfer.

Process

You can manually enter an active SCT recall (customer phones and requests a recall). The system creates an
outgoing message (camt.056) in the Output Manager for the SCT recall for the recall of external payment
items. This requests the recall of the original SCT (pacs.008) at the beneficiary bank. If the beneficiary bank
returns the SCT, it returns a pacs.004 message. If the beneficiary bank does not return the SCT, it returns
a camt.029 message (result of investigation). The Input Manager monitors and matches the camt.029 and
pacs.004 messages to existing request agents.

The process is as follows:

1. The customer can use the Create Recall BAPI (/PE1/BAPI_RECALL_CREATE) to enter the information in a
manual payment item recall. The system creates a request agent for each recall to enable monitoring and
status updates.
2. It is also possible to enter recalls by importing a camt.055 message in the Input Manager. The recalls are
assigned to the recall group 06 – Electronic. The system creates a request agent of type 08 – Customer
Recall for each recall to enable monitoring and status updates.
3. The Activate Recall BAPI (/PE1/BAPI_RECALL_ACTIVATE) searches for payment items that match the
recall.
4. If no payment item is found, the Activate Recall BAPI (/PE1/BAPI_RECALL_ACTIVATE) returns this
information to the interface. The recall is deactivated after a certain period has elapsed, and the status
of the request agent is set to Completed.
5. For electronic recalls, the status of the request agent is set to 22 (To be Forwarded) and an outgoing
camt.029 message is sent to the customer with confirmation status UWFW – UnableToApplyWillFollow via
the Request Agent Mass Processing Run with the action Forward. If the recall is deactivated after a certain
period has elapsed, the status of the request agent is set to 30 (Feedback Received) and the Feedback

Payment Engine (FS-PE)

114 PUBLIC Payment Processes
 field to 0003 (Expired) via the Request Agent Mass Processing Run with the action Expire. An outgoing
camt.029 message is sent to the customer with Confirmation status RJCR – Rejected via the Request
Agent Mass Processing Run with the action Process.
6. If a payment item is found, the system assigns the payment item to the recall. It then transfers the
payment item to Exception Handling as follows:
• If a payment item has not been posted or sent to the beneficiary bank, it does not need to be recalled
with a camt.056 message at the beneficiary bank. The system must clear only posted ordering party
items, and does so by redirecting them to a CpD account. Once the ordering party item has been
cleared in the account management system and received in FS-PE, the system sets the request agent
status to Received.
For electronic recalls, an outgoing camt.029 message is sent to the customer with a positive response
(Confirmation status CNCL – CancelledAsPerRequest) via the request Agent Mass Processing Run
with the action Process.
The following graphic shows the active recall process if a payment item has not been posted or sent to
the beneficiary bank:

Active recall process if a payment item has not been posted or sent to the beneficiary bank

If a payment item has been forwarded to the beneficiary bank after settlement, it cannot be posted to
the account management system. Therefore, the system groups the relevant payment items according
to recipient BIC from the original outgoing payment order, and uses the request agent to generate
the outgoing camt.056 message. (From the SAP Easy Access menu, you choose Payment Engine
Periodic Processing Processes Request Agent Mass Processing to schedule this in end-of-day
processing, with the action Forward.)

Payment Engine (FS-PE)

Payment Processes PUBLIC 115
 For Electronic recalls, also an outgoing camt.029 message is sent to the customer with confirmation
status PDCR – Pending CancellationRequest via the same request Agent Mass Processing Run as for
the outgoing camt.056 message to the beneficiary bank.
• A response to the camt.056 message comes from the beneficiary bank as either a camt.029
message (notification that the payment item could not be recalled) or a pacs.004 message (recall
successful) to the input converter in FS-PE. The Input Manager finds the request agent for each
message and updates its status accordingly.
• If a payment item has been forwarded to the beneficiary bank before settlement, the ordering party
account and clearing account must be balanced in the account management system before the
system can create the outgoing camt.056 message. The system groups the relevant payment items
according to recipient BIC of the original outgoing order, and uses the request agent to generate the
outgoing camt.056 message. The system assumes that either a pacs.002S2 message is returned
from the clearing house, or that the beneficiary bank returns a negative or positive response.
If the payment item has not yet been sent to the recipient bank and is processed in the same cycle
as the camt.056 message at the clearing house, the clearing house sends the pacs.002S2 message,
which is a payment cancellation report. This means that the original payment item was successfully
recalled, and nothing is sent to the recipient bank. Payment Engine (FS-PE) imports the pacs.002S2
message and creates a return posting. If this is successful, the system sets the request agent Feedback
field to 0001 (Accepted). If the pacs.002S2 message contains incorrect items (such as items that
were not found in Payment Engine (FS-PE), that have already been returned), these are written to the
import log and a request agent is created with the status 99 (Error) for each item.
For electronic recalls, an outgoing camt.029 messages is sent to the customer with a positive
response (confirmation status CNCL – CancelledAsPerRequest) in case of a positive response from the
beneficiary bank (pacs.004 message) or a successful return posting out of a pacs.002S2 message.
This is accomplished via the request Agent Mass Processing Run with the action Process. In case of a
negative response from the beneficairy bank (camt.029 message), the outgoing camt.029 message
to the customer is sent with confirmation status RJCR – RejectedCancellationRequest.
For more information, see Processing of Active Returns [page 285].

Payment Engine (FS-PE)

116 PUBLIC Payment Processes
 The following graphic shows the active recall process if a payment item has been posted and sent to
the beneficiary bank:

Active recall process if a payment item has been posted and sent to the beneficiary bank
• If a payment item is internal before settlement, the ordering party and recipient account must also
be balanced directly, similar to external payment items before settlement. The system sets the status
of the request agent to 30 (Feedback Received) after the confirmation of the ordering party items is
received from the account management system.
• If a payment item is internal after settlement, and thus has been posted, the ordering party item
(return posting order) must be postprocessed in the account management system. The system
updates the request agent status to 30 (Feedback Received).
• During end-of-day processing, the system changes the status of all the request agents from Received
to Completed. (From the SAP Easy Access menu, you choose Payment Engine Periodic Processing
Processes Request Agent Mass Processing to schedule this in end-of-day processing, with the
action Process.)
In the same request Agent Mass processing Run, an outgoing camt.029 message is sent to the
customer with the corresponding confirmation status.

Payment Engine (FS-PE)

Payment Processes PUBLIC 117
 The following graphic shows the active recall process if a payment item is internal:

Active recall process if a payment item is internal

More Information

For more information about the request agent, see Request Agent [page 150].

For more information about the passive return of SCT recalls, see Passive Recall of SEPA Credit Transfers [page
118].

For more information about recalls, see Recall [page 142].

5.2.2 Passive Recall of SEPA Credit Transfers

Use

The passive recall of SEPA credit transfers (SCT) describes what happens at the beneficiary bank when an SCT
recall takes place.

Payment Engine (FS-PE)

118 PUBLIC Payment Processes
Prerequisites

• The SEPA credit transfer is a duplicate, is technically incorrect, or has been triggered with fraudulent
intent.
• The originator bank triggers the recall within 10 bank working days of the settlement of the SEPA credit
transfer.

Process

The passive SCT recall process starts when the beneficiary bank that received and processed the original SCT
receives a request for recall. If the original SCT can be returned, the beneficiary bank creates a return order. If
the original SCT cannot be returned, or if the customer is not in agreement, the system creates and sends a
result of investigation.

If the request for recall (camt.056 message) involves a third-party institute, a request agent from the category
03 (3rd party) is created with the status 22 (To be forwarded). The file content is stored on the File Handler
Feedback tab page in the report for request agent management. In the output manager the, camt.056 file is
recreated with new assignment information in the message header.

A camt.029 feedback message updates the third-party request agent of the original camt.056 whose status
is 25 (Feedback Requested). If there is no request agent, the system creates a new one. This file content is
also stored on the File Handler Feedback tab page in the report for request agent management. The PROCESS
method recreates the camt.029 file with new assignment information in the message header.

The process for messages that do not involve a third-party financial institute is as follows:

1. The beneficiary bank receives a request for recall (camt.056 message). This message can either contain
a SEPA direct debit (SDD) request for cancellation (pacs.003 message), or an SCT recall (pacs.008
message).
• If the recall is an SDD request for cancellation, the Input Manager triggers the standard recall process.
For more information, see Request for Cancellation [page 106].
• If the recall is an SCT recall, the Input Manager creates an SCT recall object (category: SCT Recall -
Passive).
The system creates a request agent (category: SCT Recall - Passive) for monitoring and status control in
the SCT recall process.
2. You can either activate the recall process directly, or you can schedule a batch job at a specific time.
3. The system processes the recalls as follows:
• If the system finds a payment item, it transfers the payment item to Exception Handling (see no. 4) for
processing.
• If the system did not find a payment item, it sends a result of investigation to the originator bank
as a camt.029 message once the return time line has elapsed (10 bank working days, for electronic
camt.055 recalls 25 bank working days, after the camt.056 message is submitted). The system
creates the camt.029 message. (From the SAP Easy Access menu, you choose Payment Engine
Periodic Processing Processes Request Agent Mass Processing to schedule this in end-of-day
processing, using the action Expire.)
4. The system processes the payment items found as follows:
• If the payment item to be recalled is internal and has been posted, a payment order is sent to the
account management system.

Payment Engine (FS-PE)

Payment Processes PUBLIC 119
 The customer must decide whether the payment item is to be returned. If the payment item can
be recalled, this is done in the account management system in postprocessing. The system sets
the relevant status for the request agent in FS-PE. If the payment item can be recalled, the Output
Manager sends a pacs.004 message from an outgoing payment order. If a payment item cannot be
recalled, the system groups the relevant payment items according to original sender BIC of the original
incoming order, and uses the request agent to generate the camt.029 message.
• If the payment item to be recalled has not been posted, the system redirects the payment item in
FS-PE to a CpD account, and the standard return process is triggered. After return and receipt of the
return by the XI converter in FS-PE, the existing return process for creating a pacs.004 message is
triggered.

The graphic below provides an overview of the passive recall process for SEPA credit transfers:

Passive recall process for SEPA credit transfers

More Information

For more information about the request agent, see Request Agent [page 150].

For more information about the active return of SCT recalls, see Active Recall of SEPA Credit Transfers [page
114]

For more information about recalls, see Recall [page 142].

Payment Engine (FS-PE)

120 PUBLIC Payment Processes
5.3 Cash Pooling with Request for Transfer

Use

This function includes cash pools with both internal and external accounts in which a transfer of funds from
an external account to an internal account takes place. In this context originally direct debits are initiated
from the internal account to debit the external account. As direct debits are only allowed in some domestic
payment formats and under SEPA standards, some lead days are required. Payment Engine allows you to use
the initiation of a Request for Transfer.

Integration

Request for Transfer requires manual approval. Some banks agree to an automatic processing of request for
transfers. Therefore, the system provides an Enrichment and Validation check which covers the agreement
between the sending and receiving institution.

You can make settings in Customizing for Payment Engine, by choosing Payment Item Enrichment and
Validation Maintain Credit Transfer Bank Relation Payment Item . In addition, the system provides an
Enrichment and Validation check that includes the account relation between debtor and creditor.

You can make settings in Customizing for Payment Engine by choosing Payment Item Payment Item
Enrichment and Validation Maintain Preauthorized Account Relations .

Features

The following formats can be used for data transfer:

ISO Converter:

• pain.013 is a non-financial message used to request a credit payment transfer. Upon confirmation, the
customer’s account is debited and the credit transaction is released.
• pain.014 (status response to a request) is the asynchronous response to a pain.013 activation
request. Payment Engine has implemented an outbound converter to send pain.014 to other financial
institutions or customers. The request status is triggered by the existing Payment Engine function of
sender notification, which is available at Service Level Agreement level.

SWIFT-Converter:

• MT101 (Request for Transfer)

Payment Engine (FS-PE)

Payment Processes PUBLIC 121
5.4 Foreign Exchange (Overview)

SAP Payment Engine provides currency translation functions (currency exchange).

You can process foreign exchange payments in one of the following ways:

• By using a currency translation function that triggers Exception Control

You can use the currency translation function based on the identification of a foreign exchange (FX)
scenario. It covers the following steps:
• Enrichment and validation check (E&V check). For more information, see Foreign Exchange Validation.
• Errors raised by the account management system
• Predefined account currency as a default value at the route object
Once a currency exchange becomes necessary, the corresponding function in Exception Control is
triggered.
• By using an application component
You can use an internal application component of SAP Payment Engine for FX functions.
The application component translates the currencies by processing exchange rates entered in the Foreign
Currency Trade Reporting app (SAP Fiori app). The foreign currency payments are collected and then
transferred to the trading unit to determine the exchange rate.
You define the application component in Customizing for Payment Engine under Basic Settings Foreign
Exchange Assign Default Foreign Exchange (FX) Application .
The application component provides function modules that you can configure according to your business
requirements. By using these function modules, you can configure E&V checks, settlement, and clearing
processes.

You can define rates and rate types in SAP standard (SAP NetWeaver). In addition, you can make settings for
foreign currency translation in the service level agreement by creating rules in a rule set.

Related Information

Foreign Exchange (FX) [page 284]

Foreign Currency Trade Reporting [page 391]

5.4.1 Foreign Exchange Rates

There are a number of places where foreign exchange rates are displayed or can be entered in SAP Payment
Engine.

You need to distinguish between two different notation types for exchange rates:

• Exchange rates entered and stored in SAP NetWeaver tables

For currency conversions, SAP NetWeaver uses the following formulas to calculate an amount in target
currency:
• Direct Quotation:
Rate * 1 unit of company currency = 1 unit of foreign currency

Payment Engine (FS-PE)

122 PUBLIC Payment Processes
 • Indirect Quotation:
Rate * 1 unit of foreign currency = 1 unit of company currency
These rates are stored with up to 5 decimal points
• Exchange rates entered in SAP Payment Engine, for example in Foreign Currency Trade Reporting.
For currency conversions, SAP Payment Engine uses the following formula to calculate an amount in target
currency:
Direct Quotation:
Transaction amount * exchange rate = Account amount in transaction currency (direct quotation)
These rates can be entered and stored with up to 10 decimal places.

 Note

Foreign exchange target rates and amounts calculated using the SAP Payment Engine formula are stored on
the database. The rates and amount equivalens using the SAP NetWeaver formula are, however, displayed on
the UI for reference purposes.

Equivalent Calculation Function

Both Create Payment and Repair Payments include a calculate function which allows you to manually enter a
customer rate based on the SAP NetWeaver configuration scheme. The equivalent SAP Payment Engine rate is
then calculated and used for further processing.

This calculation of equivalent function can also be used when transferring foreign exchange rates in the
converter, or when passing on information to downstream systems.

Downstream Systems

The standard SAP Payment Engine interfaces pass on rates to downstream systems in direct quotation.
However, you can, for example, implement a BAdI that calls the equivalent calculator function, for example, in
order to pass on indirect quotations instead.

Spreads and Percentage Differences

Spreads or percentage differences are recorded as whole numbers. They are applied using the corresponding
formula defined in SAP NetWeaver configuration.

Cross-Currency Transactions

For cross-currency transactions, the transaction currency is first converted into the reference currency (for
example €), and then from the reference currency into the target currency.

Payment Engine (FS-PE)

Payment Processes PUBLIC 123
The mixed foreign currency rate between transaction currency and account currency is stored in the SAP
Payment Engine in remittance types.

Related Information

Foreign Currency Trade Reporting [page 391]

5.5 Batch Booking

Use

According to ISO 20022 standard, you can control how the offset posting for collective payment orders should
be made to the account. The ISO format contains a corresponding batch booking indicator. It is for the bank
to provide this service to the customers. If the indicator is set to N (no batch booking), an offset posting per
individual RCP of the payment order transaction will be created and posted (with force posting indicator).

SAP Payment Engine supports the following functions:

• An E&V Check "Batch Booking Validation" analyzes customer payments and verifies if a customer is
allowed to submit the indicator based on the identified Service Level Agreement, and if certain default
values need to be applied. As a result of this check, the batch booking indicator is set at order level.
• The batch booking indicator is available in the routing rule set to identify this type of posting scenario, for
example as part of customer clearing agreements.
• Clearing agreements have an additional option for alternative clearing scenarios. If the context of this
alternative scenario requires a prenote, the corresponding indicator can be set. A special outbound
converter implementing the batch booking logic is available.

More Information

Enrichment and Validation Check [page 313]

Service Level Agreement [page 256]

Alternative Clearing Scenarios [page 371]

Payment Engine (FS-PE)

124 PUBLIC Payment Processes
5.6 Card Transaction Processing

Use

SAP Payment Engine covers real-time channels such as card transaction processing through web services.

Payment Engine distinguishes among three different scenarios. The message families are based on ISO 8583:

• Authorization request processing (01xx)

• Financial request processing (02xx)
• Authorization reversal (04xx)

The requests are processed in timely manner and return the processing response to the sending application. A
card transaction request is an end-to-end process and includes the following steps:

The point-of-sales (POS) at which the card holder swipes the card sends the request to the central switch
solution. The switch validates the PIN, if provided. It performs several actions and forwards the request to
SAP Payment Engine. Payment engine returns the processing response based on configuration to the switch.
In case the backend is not available, the switch can also provide stand-in functionality. As a consequence,
the result of the request is sent back to the POS indicating the device whether the transaction is approved.
Subsequent transaction requests can relate to each other building message chains. In terms of ISO 8583, for
example, an authorization request (0100) is followed by a financial processing advise (0220) which can be later
reversed by an authorization reversal (0400).

For the integration between switch and SAP Payment Engine there are synchronous and asynchronous web
services available (see Enterprise Services for Payment Engine [page 155]). The switch can either consume
the business services and directly create and process a payment order (also see Payment Transaction Order
In [page 157]) or recall (see Action Payment Transaction Order [page 160]). Alternatively, the payment engine
connector (see Payment Engine Connector [page 163]) can be used to transfer the original data format
and leverage the file handler data conversion functionality. Asynchronous integration can be done using the
Financial Services Network Service Provider (see Financial Services Network Integration [page 305]).

SAP Payment Engine provides input converter for ISO 8583 messages using the payment transaction
connector (see Payment Engine Connector [page 163]).

More Information

Authorization Request Processing [page 126]

Financial Request Processing [page 127]

Authorization Reversal [page 128]

Payment Engine (FS-PE)

Payment Processes PUBLIC 125
5.6.1 Authorization Request Processing

Use

The authorization request is an end-to-end process and includes the following steps:

The point-of-sales (POS) at which the card holder swipes the card sends an authorization request to the central
switch solution. The switch validates the PIN, if provided. It performs several actions and forwards the request
to SAP Payment Engine. As a result, Payment Engine requests a reservation of the amount in the respective
account management system and returns the result to the switch. Consequently, the result of the authorization
request is sent back to the POS indicating the device whether the amount is approved.

The authorization request creates a dedicated one-sided order object in SAP Payment Engine containing
multiple items of category 05 – Reservation Request. Upon processing the order, the order STP process follows
(see Payment Processing (FS-PE-POP) [page 309]) with limited clearing functionality. Reservation requests are
limited to direct processing into the accounting system to create a prenote on the customer account.

These messages belong to the 01xx family of authorizations based on ISO 8583.

The following message types are supported:

• 0100 – Authorization Request

• 0110 – Request Response (Outgoing)
• 0120 – Authorization Advice
• 0121 – Authorization Advice Repeat
• 0130 - Issuer Response to Authorization Advice (Outgoing)

Activities

You can control the processing of the created objects using the following BAdI:

Choose File Handler Business Add-Ins (BAdIs) BAdI: Free Message Integration

You perform the default implementation in Customizing for Payment Engine by choosing:

File Handler Financial Message Service Integration Assign Converter IDs to Free Message Types
(Inbound)

File Handler Financial Message Service Integration Control Payment Order Process

More Information

ISO 8583 Converter [page 301]

Payment Engine (FS-PE)

126 PUBLIC Payment Processes
5.6.2 Financial Request Processing

Use

The financial request processing triggers a posting to the customer account. In case of a dual-message process
during which an authorization message (01xx family) has been received, the financial message is the second
message triggering the actual posting. This scenario belongs to the 02xx family of messages based on ISO
8583.

The following message types are supported:

• 0200 – Acquirer Financial Request

• 0210 – Issuer Response to Financial Request (Outgoing)
• 0220 – Acquirer Financial Advice
• 0221 – Acquirer Financial Advice Repeat
• 0230 – Issuer Response to Financial Advice (Outgoing)

Processing of the created objects can be controlled by using BAdI /PE1/BADI_MSG_INTV1.

Activities

You can control the processing of the created objects using the following BAdI:

Choose File Handler Business Add-Ins (BAdIs) BAdI: Free Message Integration

You perform the default implementation in Customizing for Payment Engine by choosing:

File Handler Financial Message Service Integration Assign Converter IDs to Free Message Types
(Inbound)

File Handler Financial Message Service Integration Control Payment Order Process

Prenote matching between financial request and reservation request is done during E&V using an external item
reference (message UUID).

More Information

ISO 8583 Converter [page 301]

Payment Engine (FS-PE)

Payment Processes PUBLIC 127
5.6.3 Authorization Reversal

Use

The authorization reversal creates a recall that is then directly processed. An authorization or financial
transaction that has been sent earlier needs to be reversed due to a cancellation of the actual transaction.
For that reason, the available amount of the customer’s account no longer contains the reversed amount. If
the original transaction is a financial message that is already posted, a return order is generated to credit the
customer’s account referencing the original transaction.

Based on ISO 8583 the following message types are supported:

• 0400 – Acquirer Reversal Request

• 0420 – Acquirer Reversal Advice
• 0421 – Acquirer Reversal Advice Repeat Message
• 0430 – Issuer Reversal Response (Outgoing)

Reversal requests are realized as recall objects following standard processing (also see Recall [page 142]). New
exception handling reaction types area available for reservation requests to cancel or reverse a prenote and to
accept amount adjustments for reservations. For more information, see Exception Control (FS-PE-EH) [page
265].

You can control the processing of the created objects using the following BAdI:

Choose File Handler Business Add-Ins (BAdIs) BAdI: Free Message Integration

Activities

You perform the default implementation in Customizing for Payment Engine by choosing:

File Handler Financial Message Service Integration Assign Converter IDs to Free Message Types
(Inbound)

More Information

ISO 8583 Converter [page 301]

Recall [page 142]

Payment Engine (FS-PE)

128 PUBLIC Payment Processes
6 Clearing Area

Definition

An organizational unit within payment operations.

Most business objects and business rules used in payment processing are separated at clearing-area level.
Clearing areas act as a substructure under the client level.

Use

In Payment Engine, you can define clearing areas based on the following criteria:

• Business requirements (clearing and settlement setup):

Each clearing area has its own set of business rules and business objects. End-of-day processing is
performed separately for each clearing area. For more information, see End-of-Day Processing (FS-PE-
EOD) [page 403].
• Level of central control and separation of data:
At clearing-area level, you must define a separate set of control data so that the processes in each clearing
area can be controlled separately.
• Authorization
For each clearing area, you can control which Payment Engine objects users are allowed to display or edit
and which actions users are allowed to perform.

You can model more than one clearing area in one client depending on your business requirements. Thus, you
can handle special clearing scenarios faster and more efficiently or you can deploy Payment Engine in a data
center to control the processes in each clearing area separately.

The clearing area plays an important role in most Payment Engine components. The following data is separated
at clearing-area level:

• Master data
Particularly, routes, clearing agreements, and their rule sets, as well as exception control rule sets with
their response types
• Transaction data
Payment orders and payment items
• Customizing data
Particularly, account management areas, transaction types for payment items, payment order types, and
checks for enrichment and validation

You define clearing areas and their attributes in Customizing for Payment Engine under Basic Settings
Organization Define Clearing Area .

Payment Engine (FS-PE)

Clearing Area PUBLIC 129
Structure

The following main attributes specify a clearing area:

• General calendar
This calendar determines the processing days at clearing-area level.

 Note

In the context of SEPA payment transactions, you can use the TARGET days calendar. TARGET is the
Trans-European Automated Real-time Gross Settlement Express Transfer System. The TARGET days
calendar is used to identify inter-bank business days.

• Release currency
This currency is the currency used for clearing.
• Indicator for determining whether plausibility checks are executed for the bank key during transfer posting
• Indicator for determining whether plausibility checks are executed for the account number during transfer
posting
• Indicator for rerouting
This indicator determines whether an alternative route is calculated if an error occurs.
• TARGET days calendar
• Indicator to determine whether the previous or the next business date is used to update the processing
date if the processing date is not a valid bank workday.
• Indicator for ordering party item collection
• Value date calendar
This calendar is used to calculate the value date.
• Payment advice for multi-collection

Integration

Bank keys must be assigned to clearing areas:

An internal bank key is assigned to one clearing area. Multiple internal bank keys can be assigned to one
clearing area. The bank key determines whether a payment order is internal or external. If the bank key of
a payment order matches a bank key assigned to the clearing area, then the order is internal and can be
further processed in the corresponding clearing area. You assign bank keys to clearing areas in Customizing
for Payment Engine under Basic Settings Organization Assign Bank Key to Clearing Area and Contract
Partner .

Usually, one clearing area in Payment Engine corresponds to one bank posting area in a connected account
management system in order to handle accrual and reconciliation processes consistently. You define bank
posting areas in Customizing for Payment Engine under Basic Settings Account Management Systems
Define SAP AM Bank Posting Area . For more information about the accrual and reconciliation processes, see
Accrual [page 405] and Reconciliation [page 407].

Payment Engine (FS-PE)

130 PUBLIC Clearing Area
Example

A bank models its Payment Engine system as follows:

• In clearing area A, all payment orders regarding savings accounts are processed.
• In clearing area B, all payment orders regarding current accounts are processed.
• In clearing area C, all payment orders regarding savings accounts and current accounts are processed.

Example 1: Modeling of clearing areas

Another bank models its Payment Engine system as follows:

• In clearing area D, all payment orders of the London branch are processed.
• In clearing area E, all payment orders of the Hamburg branch are processed.
• In clearing area F, all payment orders of the Paris branch are processed.

Payment Engine (FS-PE)

Clearing Area PUBLIC 131
 Example 2: Modeling of clearing areas

Payment Engine (FS-PE)

132 PUBLIC Clearing Area
7 Payment Order

Definition

An instruction to transfer a determined amount of money between one or more accounts of one or more
financial institutions.

Use

You can create payment orders in Payment Engine by importing a file. For more information, see File Handler
(FS-PE-FH) [page 289].

You can also create and change payment orders, import incoming payment orders, export outgoing payment
orders, and process and postprocess payment orders manually.

To process payment orders, on the SAP Easy Access screen, choose Payment Engine Payment Order
Management Edit Payment Orders (Expert) (transaction /PE1/PO_EXPERT). For more information, see
Edit Payment Orders (Expert) [page 373].

Furthermore, you can process payment orders in batch using the Poller report. To run this report, on the
SAP Easy Access screen, choose Payment Engine Periodic Processing Processes Execute Processes
(transaction /PE1/POLLER).

You can define your own payment order types in Customizing. These settings specify process control
characteristics such as the checks that the system must make and the relevant field selection control. For
more information, see Enrichment and Validation [page 311].

You make these settings in Customizing for Payment Engine under Payment Order Define Payment Order
Types .

Structure

A payment order is uniquely defined by the following parameters:

• Clearing area
Specifies the legally independent organizational unit where a payment order was created or imported from.
• Payment order number
Determined by a number range that is defined in Customizing for Payment Engine under Payment Order
Maintain Number Ranges of Payment Order .
• Payment order date
The system retrieves the payment order date based on the reconciliation date defined in Payment Engine.

Payment Engine (FS-PE)

Payment Order PUBLIC 133
Every payment order comprises information that is stored as attributes and grouped on different tab pages. For
more information, see Payment Order and Payment Item Overview [page 375].

Integration

A payment order generally comprises different payment items categories: an ordering party item, which
represent the ordering party and therefore a payment instruction, and one or more recipient items, that is, the
items to which a payment is transferred. For more information, see Payment Item [page 138].

Payment orders can represent:

• Internal payments
A payment transfer takes places between accounts managed by the same financial institution. The
payment order is entered directly in Payment Engine or imported from a file for processing by Payment
Engine. The payment is forwarded to an internal account management system.
• External payments
A payment is transferred between accounts managed by different financial institutions. The payment order
is entered directly in Payment Engine or imported from a file for processing by Payment Engine. The route
determines that the payment is external and after processing in Payment Engine, the payment is posted to
an internal account as a clearing item and the payment data is sent to an external account management
system in an outgoing payment order.

For auditing purposes, certain transactions must always be checked and authorized by at least one other
employee. For this purpose, a release function with a connection to the workflow based on the principle of
dual, treble, or quadruple control is used. You define these specific settings in Customizing for Payment Engine
under Payment Order Release for Payment Order . For more information, see Release Workflow [page
419] and Release Object ORDER (Payment Order) [page 135].

Incoming payment orders can comprise one or more ordering party items and one or more recipient items. The
account related to an ordering party item and the accounts of the recipient items are generally different.

 Example

Incoming payment order

• One ordering party to many recipients

Salary payment by a company: The ordering party is a company, the recipients are the employees.
• One ordering party to one recipient
Simple funds transfer

Incoming payment orders can have several ordering party items for the following reasons:

• The file used to import the payment order into Payment Engine contains more than one ordering party
item.
• During payment processing, an ordering party item is split into several items based on the setting defined
in the customer service level agreement (SLA).
The system checks whether the ordering party item for this payment order type is to be split based on the
transaction type group of the recipient item or based on the reference account number of the recipient
item.
For more information, see Service Level Agreement [page 256].

Payment Engine (FS-PE)

134 PUBLIC Payment Order
Outgoing payment orders can comprise one ordering party item, one or more recipient items, and one clearing
item.

 Example

Outgoing payment order

Payment items are bundled in a clearing collector. When the clearing collector closes, the system generates
an outgoing payment order to which it adds a clearing item. The sum of all payment items is posted to a
clearing account and the payment items are forwarded to an external account management system in just
one payment order.

The way payment orders are processed in Clearing Processing depends on whether they contain internal
payment items or external payment items and whether payment items need to be collected or queued.

For more information, see Routing Control (FS-PE-RP) [page 205] and Clearing Processing (FS-PE-CP) [page
337].

7.1 Release Object ORDER (Payment Order)

Definition

A release object in Payment Engine (FS-PE) used by the system to identify whether the editing of a payment
order by an author or a processor is subject to release.

If the editing of the payment order is subject to release, the system generates a release object ORDER (payment
order) as a work item that can be processed further by a supervisor or user responsible for release in the
Business Workplace.

Use

Customizing

In Customizing, you can define how many release steps the object must pass (for example, for dual or treble
control) and the conditions when the release workflow is carried out (for example, always, conditional by using
release attributes).

You make the settings for release object ORDER in Customizing for Payment Engine (FS-PE) under Payment
Order Release for Payment Order in the following Customizing activities:

• Assign Release Procedure to Release Object

• Assign Standard Role to Release Steps
• Assign Workflow and Sub-Workflow to Release Procedure

Channel

Dialog

Payment Engine (FS-PE)

Payment Order PUBLIC 135
Individual processing: transaction Edit Payment Orders (Expert) (/PE1/PO_EXPERT)

The system checks whether the dialog processing of the payment order is subject to release, and generates
a work item for every release-relevant payment order. If a payment order is no longer subject to release after
processing, the system deletes the associated work item.

Mass processing: transaction Execute Processes (/PE1/POLLER)

The system checks whether the mass processing of payment orders is subject to release, and generates a
work item for every release-relevant payment order. If a payment order is no longer subject to release after
processing, the system deletes the associated work item.

Business Application Programming Interface (BAPI)

Like during dialog processing, the system checks whether editing a payment order by using BAPIs is subject to
release and generates a work item for every release-relevant editing. If a payment order is no longer subject to
release after editing, the system deletes the associated work item.

Structure

You can edit release object ORDER as a work item in the Business Workplace. These methods can affect the
status of the payment order:

• Display
Choosing this pushbutton brings you to the dialog transaction Edit Payment Orders (Expert).
• Change
Choosing this pushbutton brings you to the dialog transaction Edit Payment Orders (Expert). The system
closes the old release workflow and triggers a new release process with the changed data. The status of the
new payment order release object is initially For Release.
This method in the Business Workplace can change the status and release status of the payment order as
follows:
The system checks the changed payment order and generates a new work item if applicable and deletes
the existing work item.
• Release
This method in the Business Workplace can change the status and release status of the payment order as
follows:
Processing the payment order:

Before Release After Release

Status of the Pay- Release Status Release Activity Status of the Pay- Release Status
ment Order ment Order

105, 110, or 170 For Release Processing Depending on the set- Released
tings: 117, 120, 128,
170, 311

Payment Engine (FS-PE)

136 PUBLIC Payment Order
 Editing the payment order:

Before Release After Release

Status of the Pay- Release Status Release Activity Status of the Pay- Release Status
ment Order ment Order

105, 110, or 170 For Release Change 105, 110, or 170 if cre- Released
ated or changed

• Reject
Choosing this pushbutton rejects the change of the payment order. You can create an attachment stating a
rejection reason.
This method in the Business Workplace can change the status and release status of the payment order as
follows:
Processing the payment order:

Before Release After Release

Status of the Pay- Release Status Release Activity Status of the Pay- Release Status
ment Order ment Order

105, 110, or 170 For Release Processing 105, 110, or 170 Rejected

Editing the payment order:

Before Release After Release

Status of the Release Status Release Activity Status of the Payment Release Status
Payment Order Order

105, 110, or 170 For Release Change 105, 110, or 170 if created Rejected
or changed

More Information

Payment Order [page 133]

Edit Payment Orders (Expert) [page 373]

Payment Engine (FS-PE)

Payment Order PUBLIC 137
8 Payment Item

Definition

An individual posting to a determined account that is assigned to a payment order.

Use

You can create payment items in Payment Engine by importing a file. For more information, see File Handler
(FS-PE-FH) [page 289].

You can also create payment items manually, and change, reject, redirect, process, and postprocess individual
payment items. On the SAP Easy Access screen, choose Payment Engine Payment Order Management
Edit Payment Orders (Expert) (transaction /PE1/PO_EXPERT). For more information, see Edit Payment
Orders (Expert) [page 373].

Furthermore, you can process payment orders and their related items in batch using the Poller report. To run
this report, on the SAP Easy Access screen, choose Payment Engine Periodic Processing Processes
Execute Processes (transaction /PE1/POLLER).

Payment items have different statuses during straight-through processing (STP) that influence how the system
processes the payment items.

A payment item typically has one of the following statuses:

• Collected
The payment item has already been assigned to an account, but is not yet included in the account balance.
• Queued
The payment item is waiting to be manually released or is scheduled to be processed later.
• Posted
The payment item has been posted to an internal account.
• In Postprocessing
The payment item has been removed from STP due to errors and requires manual postprocessing.

Payment items contain regulatory reporting data. In Payment Engine, regulatory reporting data is generally not
referenced and is stored for regulatory and auditing purposes.

Some payment items also contain additional payment information, such as a note to payee or information
about charges. You can define text modules for additional payment information in Customizing for Payment
Engine under Basic Settings Text Modules . You can also define the text that is attached to new payment
items that are generated in Payment Engine in Customizing for Payment Engine under Basic Settings Text
Modules Define Payment Note for New Payment Item .

Payment Engine (FS-PE)

138 PUBLIC Payment Item
Structure

Payment items are uniquely defined by the following parameters:

• Clearing area
Specifies the legally independent organizational unit where a payment item was created or imported from.
• Payment item number
Determined by a number range that you define in Customizing for Payment Engine under Payment Items
Maintain Number Ranges of Payment Items .
• Payment item date
Date retrieved from the reconciliation date. On the SAP Easy Access screen, choose Payment Engine
Periodic Processing End-of-Day Processing Set PE Reconciliation Date Set Reconciliation Date
(transaction /PE1/EOD_SET_DATE).

Every payment item comprises information that is stored as attributes and grouped on different tab pages. For
more information, see Payment Order and Payment Item Overview [page 375].

Integration

All payment items share common properties and are assigned to a payment order.

Payment items are divided into the following categories:

• Ordering party item

• Recipient item
• Clearing item
• Turnover item

You can define transaction types for payment items in Customizing for Payment Engine under Payment
Items Transaction Types and Transaction Types Groups . These settings specify process control
characteristics such as the checks to be made and a relevant field selection control. For more information,
see Enrichment and Validation [page 311].

For auditing purposes, certain transactions must always be checked and authorized by at least one other
employee. For this purpose, a release function with a connection to the workflow based on the principle of dual,
treble, or quadruple control is used.

You define these specific settings in Customizing for Payment Engine under Payment Items Release
for Payment Item . For more information, see Release Workflow [page 419] and Release Object POITEM
(Payment Item) [page 140].

Payment Engine (FS-PE)

Payment Item PUBLIC 139
8.1 Release Object POITEM (Payment Item)

Definition

A release object in Payment Engine used by the system to identify whether the editing of a payment item by an
author or a processor is subject to release.

If the editing of the payment item is subject to release, the system generates a release object POITEM
(payment item) as a work item that can be processed further by a supervisor or user responsible for release in
the Business Workplace.

Use

Customizing

In Customizing, you can define how many release steps the object must pass (for example, for dual or treble
control) and the conditions when the release workflow is carried out (for example, always, conditional by using
release attributes).

You make the settings for release object POITEM in Customizing for Payment Engine under Payment Items
Release for Payment Items in the following Customizing activities:

• Assign Release Procedure to Release Object

• Assign Standard Role to Release Steps
• Assign Workflow and Sub-Workflow to Release Procedure

Channel

Dialog

Individual processing: transaction Edit Payment Orders (Expert) (/PE1/PO_EXPERT)

The system checks whether the dialog processing of the payment item is subject to release, and generates
a work item for every release-relevant payment item. If a payment item is no longer subject to release after
processing, the system deletes the associated work item.

Mass processing: transaction Execute Processes (/PE1/POLLER)

The system checks whether the mass processing of payment items is subject to release, and generates a work
item for every release-relevant payment item. If a payment item is no longer subject to release after processing,
the system deletes the associated work item.

Business Application Programming Interface (BAPI)

Like during dialog processing, the system checks whether editing a payment item by using BAPIs is subject to
release and generates a work item for every release-relevant editing. If a payment item is no longer subject to
release after editing, the system deletes the associated work item.

Payment Engine (FS-PE)

140 PUBLIC Payment Item
Structure

You can edit release object POITEM as a work item in the Business Workplace. These methods can affect the
status of the payment item.

• Display
Choosing this pushbutton opens the dialog transaction Edit Payment Orders (Expert).
• Change
Choosing this pushbutton opens the dialog transaction Edit Payment Orders (Expert). The system closes
the old release workflow and triggers a new release process with the changed data. The status of the new
payment item release object is initially For Release.
This method in the Business Workplace can change the status and release status of the payment item as
follows:
The system checks the changed payment item and generates a new work item if applicable and deletes the
existing work item.
• Display change documents
Choosing this pushbutton opens the dialog transaction Edit Payment Orders (Expert) with dialog box
Display Change Documents of the payment item.
• Release
This method in the Business Workplace can change the status and release status of the payment item as
follows:
Editing the payment item:

Before Release After Release

Status of the Pay- Release Status Release Activity Status of the Pay- Release Status
ment Item ment Item

05, 10, or 70 For Release Change 05, 10, or 70 Released

More Information

Payment Item [page 138]

Edit Payment Orders (Expert) [page 373]

Payment Engine (FS-PE)

Payment Item PUBLIC 141
9 Recall

Definition

An instruction to the recipient of a payment order from the ordering party of a payment order to cancel
processing of the payment order or recipient items.

A distinction is made between the recall of a payment order and the recall of a recipient item.

Use

You can cancel payment processing of a complete payment order or single recipient items within a batch of
payments by creating recalls. A recall can be of the following recall types:

• Bank payment order recall of a complete payment order

• Customer payment order recall of a complete payment order
• Bank item recall of a single recipient item
• Customer item recall of a single recipient item

You can create recalls manually by uploading a recall document or the system creates recalls when it receives a
file from a feeder system that contains the recall data. When a recall is created, the system assigns it to one of
the following recall groups:

• Manual
For recalls that you create manually
• SWIFT
For recalls converted from the SWIFT message format
• SDD Recall
For recalls converted from a request to cancel a SEPA Direct Debit (SDD) transaction
For more information about manual and SWIFT recalls, see Recall Processing [page 147]. For more
information about requests for cancellation, see Request for Cancellation [page 106].
• Active SCT Recall
When you create an active SCT recall, FS-PE creates a corresponding request agent object. For more
information about active SCT recalls, see Active Recall of SEPA Credit Transfers [page 114].
• Passive SCT Recall
When you create a passive SCT recall, FS-PE creates a corresponding request agent object. For more
information about SCT passive recalls, see Passive Recall of SEPA Credit Transfers [page 118].
• Electronic Recall
For recalls converted from an electronic customer recall. When you create an electronic customer recall,
a corresponding request agent is being created. For more information, see Active Recall of SEPA Credit
Transfers [page 114].

You can define the attributes that are required, optional, and additional in recalls in Customizing for Payment
Engine under Recall Management Maintain Recall Mandatory Fields .

Payment Engine (FS-PE)

142 PUBLIC Recall
You manage recalls either in dialog mode or by using Business Application Programming Interfaces (BAPIs).
To do so in dialog mode, choose Payment Order Management Manage Recalls from the SAP Easy Access
menu.

For more information, see Recall Management [page 144].

Structure

A recall consists of required, optional, and additional attributes that you can define. These vary, depending on
whether the recall is for a payment order or a payment item.

A recall can have one of the following statuses:

Recall Status Description

Manually Created The system has detected the recall data, but neither the
system nor a user has activated it yet.

Active The system or a user has activated the recall and the system
searches for matching payment orders or payment items.

Partially Active The system has found matching payment items. However,
the identified payment items are currently locked by another
process. Therefore, the payment recall needs to be activated
again at a later time.

Matched The system has found matching payment orders or payment

items.

In Post-Processing Due to errors during recall activation or processing, manual

user actions are required. Possible actions are, for example,
to finalize the payment recall or to continue while ignoring
errors.

Inactive The system or the user has deactivated the recall – match-
ing payment orders or payment items were already posted
or cleared.

Legally Active The system or the user has deactivated the recall but
matching payment items were previously processed. For le-
gal and archiving reasons this status is different than the
Inactive status and is called Legally Active.

Payment Engine (FS-PE)

Recall PUBLIC 143
9.1 Recall Management

Use

You can recall payment orders and payment items to cancel processing of payments for payment orders and
payment items that have not been finally processed.

You can search for a payment order or a payment item either in the Payment Engine database when you
activate a recall or during processing by an enrichment and validation check. For more information, see
Enrichment and Validation [page 311].

Moreover, you can trigger automatic recall activation and processing with subsequent recall finalization.

Prerequisites

• Depending on your specific recall implementation, you have performed the following activities in
Customizing for Payment Engine (FS-PE):
• Recall BAdI: Implementation of User Methods for Recall .
• Payment Order Business Add-Ins (BAdIs) BAdI: Call of Recall Maintenance Screen .
• Maintain the settings necessary for managing recalls in Customizing for Payment Engine (FS-PE) in the
activities under Recall :
• Payment Order Define Payment Order Types
• Payment Item Transaction Types and Transaction Type Groups Maintain and Assign Transaction
Types for Payment Items
• You have implemented the function modules of the Business Application Programming Interfaces (BAPIs)
that you want to use (transaction SE37).
• You have specified whether you want to process recalls manually or whether you want the system
to process recalls automatically in Customizing for Payment Engine by choosing Recall Maintain
Automatic/Manual Recall Processing Indicator .
• You have specified further recall processing options in Customizing for Payment Engine by choosing
Recall Maintain Recall Processing Options .

Features

You can manage recalls in the dialog mode. From the SAP Easy Access screen, choose Payment Order
Management Manage Recalls .

The tree structure in the left-hand window displays a hierarchy of recalls from which you can select a recall for
display or processing. The recalls are grouped for payment orders or payment items, and according to whether
they were initiated by banks or customers. Each category is divided into types and statuses, such as Active,

Payment Engine (FS-PE)

144 PUBLIC Recall
Matched, Legally Active or Inactive. You can display these according to data source, by choosing Extras
Change Data Source from the application toolbar.

On the screen for recalls, you can choose the relevant button from the application toolbar to do various recall
tasks such as creating, editing, or setting the status of a recall.

 Note

• If you copy a recall, you can use this as a template to create a new recall.
• If you show the matches for a recall, you can display a list of items at the bottom of the screen that
match the specified recall criteria. You can then process, dismiss, or convert recalls included in the
matching list. You can also navigate to the PO Expert screen from here. You can display a log of the
payment items in the recall, and a change history.
• If you display the request agent details, you can navigate to the request agent screen from here.

The tab pages displayed differ according to whether the recall is for a payment item or a payment order. You
can use these tab pages to specify or change the criteria used for recall matching.

You can decide whether to transfer the recalled payment orders or payment items to Exception Control. If you
do not want to recall the payment order or payment items even though these payment orders or payment
items match recalls identified during enrichment and validation, you can return the recalled payment orders or
payment items to straight-through processing (STP).

For more information, see End-to End Payment Processing [page 98].

Checks

When you create new recalls, the system checks the following:

• Whether you have entered the required data as defined in Customizing for Payment Engine (FS-PE), under
Recall .
• Whether you have specified at least one attribute

During activation, the system checks the following:

• Whether activation is complete or was stopped due to unexpected errors. If this is the case, the system
requires that you reactivate later.
• Recall submission authorization for format, medium, and channel as specified by the recall's Service Level
Agreements.
• Recall submission cut-off times as specified by the recall's Service Level Agreements.

BAPIs

You can use BAPIs to manage your recalls as follows:

Task Business Application Programming Interface (BAPI)

Create a recall /PE1/BAPI_RECALL_CREATE

Activate an existing recall /PE1/BAPI_RECALL_ACTIVATE

Specify whether matching payment orders or payment /PE1/BAPI_RECALL_PROCESS

items are to be recalled

Payment Engine (FS-PE)

Recall PUBLIC 145
Task Business Application Programming Interface (BAPI)

Deactivate a recall /PE1/BAPI_RECALL_DEACTIVATE

Set the status of a recall to Legally Active /PE1/BAPI_RECALL_LEGALLY_ACTIV

Change a recall /PE1/BAPI_RECALL_CHANGE

Show all data for a recall and archived recall data /PE1/BAPI_RECALL_GETDETAIL

Search for recalls using search criteria /PE1/BAPI_RECALL_GETLIST

Show all matching objects /PE1/BAPI_RECALL_GETMATCHEDITEMS

The system transfers recalled payment orders or payment items to Exception Control.

For more information, see Exception Control (FS-PE-EH) [page 265].

Activities

• Create a recall manually by choosing Payment Order Management Manage Recalls from the SAP
Easy Access screen. Alternatively you can use BAPI /PE1/BAPI_RECALL_CREATE. You can upload recall
files as defined in Customizing. If you upload a SWIFT format recall, use a SWIFT MT 192 file.

 Note

The following attributes are populated automatically:

• Date of the Recall Creation
• Creator of the Recall
• Recall Status
• Recall ID
• Date Valid Until (if you leave this blank, a value is calculated automatically)

• Process a recall manually by choosing Payment Order Management Manage Recalls from the SAP
Easy Access screen. Alternatively, you can use BAPI /PE1/BAPI_RECALL_PROCESS.

 Note

You can process only payment orders or payment items with the status Matches Found.

• Check the status of recalls in the system by choosing Payment Order Management Manage Recalls
from the SAP Easy Access screen.

More Information

Recall [page 142]

Payment Engine (FS-PE)

146 PUBLIC Recall
Recall Processing [page 147]

Active Recall of SEPA Credit Transfers [page 114]

Passive Recall of SEPA Credit Transfers [page 118]

9.2 Recall Processing

Use

You can use this process to cancel payment processing of a complete payment order or single recipient items
within a batch of payments in Payment Engine.

Recall processing involves:

• Submitting recalls to Payment Engine

• Activating recalls manually or automatically
• Matching recalls with payment orders and payment items during enrichment and validation
• Processing recalls manually

Prerequisites

You have implemented the recall management activities that you require in Customizing for Payment Engine.
For more information, see Recall Management [page 144].

You can use recall management only for payment orders and recipient items that have not been finally
processed.

Process

 Note

You can display an overview of status transitions for recalls in Customizing for Payment Engine under
Tools Functional Monitoring Display Status Transitions Display Status Transitions of Recalls .

1. You manually upload a recall document to Payment Engine or Payment Engine automatically receives a file
from a feeder system that contains the recall data.
The system automatically accepts recalls through the following:
• Business Application Programming Interface (BAPI)
• Society for Worldwide Interbank Financial Telecommunication (SWIFT) file
2. You activate the recall manually or the system activates it automatically (for example, when you submit a
SWIFT file).

Payment Engine (FS-PE)

Recall PUBLIC 147
 After a recall is created, the status of the recall must be set to Active to trigger a search for matching
payment orders or payment items. The status of recalls submitted in a SWIFT file is automatically set to
Active.
3. During the enrichment and validation process, the system searches for active recalls that match the
payment orders and/or payment items.
• If the system finds a recall for a payment order or payment items during manual recall processing, it
sets the recall status to Matched.
• If the system finds one or more matching payment orders or payment items during automatic recall
processing, it sets the recall status to Legally Active and the system recalls the payment orders or
payment items.

 Note

In the recall database table, the Format Group attribute and certain Format Types can flag their
corresponding payment orders or payment items as Recalled. These payment orders or payment items
are then processed during exception handling.

For more information, see Exception Control (FS-PE-EH) [page 265].

More Information

For more information, see the following documentation:

• Recall [page 142]

• Recall Management [page 144]
• Enrichment and Validation [page 311]
• Active Recall of SEPA Credit Transfers [page 114]
• Passive Recall of SEPA Credit Transfers [page 118]

9.3 Release Object RECALL (Recall)

Definition

A release object in Payment Engine used by the system to identify whether the editing of a recall by an author
or a processor is subject to release.

If the editing of the recall is subject to release, the system generates a release object RECALL (recall) as a work
item that can be processed further by a supervisor or user responsible for release in the Business Workplace.

Use

Customizing

Payment Engine (FS-PE)

148 PUBLIC Recall
In Customizing, you can define how many release steps the object must pass (for example, for dual or treble
control) and the conditions when the release workflow is carried out (for example, always, conditional by using
release attributes).

You make the settings for release object RECALL in Customizing for Payment Engine under Recall
Management Release for Recalls in the following Customizing activities:

• Assign Release Procedure to Release Object

• Assign Standard Role to Release Steps
• Assign Workflow and Sub-Workflow to Release Procedure

Channel

Dialog and Business Application Programming Interface (BAPI)

The system checks whether you need to release a recall. If this is the case, the system generates a work item
each time. If a recall is no longer subject to release after editing, the system deletes the associated work item.

Structure

You can edit release object RECALL as a work item in the Business Workplace. These methods can affect the
status of the recall.

More Information

For more information, see Recall [page 142].

Payment Engine (FS-PE)

Recall PUBLIC 149
10 Request Agent

Definition

This object enables you to monitor a particular process that can involve subprocesses, both in Payment Engine
(FS-PE) and external systems.

Use

The request agent has a life cycle as indicated by its status, such as triggered or completed. A change of status
can trigger an action for example to forward a request. In addition, each request agent has a type and contains
references to other related objects such as a feedback file.

Batch operations can be scheduled based on the status of release agents. For example, the poller report
selects all request agents with a specific status to be forwarded and sends them externally at a designated
time.

Payment Engine (FS-PE)

150 PUBLIC Request Agent
 The graphic above shows the life cycle of the request agent.

One example is a request agent monitoring the SEPA credit transfer (SCT) recall process. A request agent is
created by an incoming object, in this case an SCT recall. This request agent is specific to the incoming SCT
recall that created it and holds data on this SCT recall that is used to track it throughout its life cycle. In this
case there are two types of request agent determined by the type of SCT recall: active SCT recall or passive
SCT recall.

Structure

The data held on a request agent includes the following.

• Status
• Previous status
• Type of request agent
• Information
• References to incoming data, reference object, forward object, and received object
In each group box, you can choose the icon to show more details about the referenced objects.

Payment Engine (FS-PE)

Request Agent PUBLIC 151
Integration

You can call the report that lists the current request agents from the SAP Easy Access menu by choosing
Payment Engine Request Agent Management Manage Request Agents .

Every process to be monitored by request agents needs to be adapted to update the request agents associated
with it. The monitored process is determined by the type of request agent. To create a new request agent type,
do the following:

1. Define the request agent type specifying the implementing class for the interfaces /PE1/IF_REQ_AGENT
and /PE1/IF_REQ_AGENT_REP in view /PE1/V_REQ_AGTY.
2. Create the technical implementations associated with the configured class in the previous step.
3. Update your process accordingly to search and update the associated request agents in the different steps.

More Information

• Active Recall of SEPA Credit Transfers [page 114]

• Passive Recall of SEPA Credit Transfers [page 118]
• Archiving Object /PE1/RAG [page 431]
• For more information about Customizing settings related to the request agent, see Customizing for
Payment Engine (FS-PE), under Request Agent .

Payment Engine (FS-PE)

152 PUBLIC Request Agent
11 Connection of Internal and External
Systems

Use

Payment Engine provides connections to the feeder and forwarding systems for input and output of payment
transaction data as part of its core functionality. Using the SAP NetWeaver platform, you can connect
other systems to Payment Engine through Business Application Programming Interfaces (BAPIs) and remote
function calls (RFCs). Thus, you can make use of account-management (AM), embargo, and money-laundering
systems as well as middleware or front-end applications.

Moreover, you can use enterprise services for payment transactions. For more information, see Enterprise
Services for Payment Engine [page 155].

The following figure shows an example of a system landscape for Payment Engine including an account-
management system (AMS).

Payment Engine Overview

For more information about the communication between Payment Engine and external feeder systems and
forwarding systems, see File Handler (FS-PE-FH) [page 289].

You can also submit payment transaction data from external systems in online mode over the payment order
interface.

Payment Engine (FS-PE)

Connection of Internal and External Systems PUBLIC 153
The following figure shows the potential integration of Payment Engine in the front end and middleware as well
as possible real-time or other interfaces across the SAP NetWeaver integration and application platform.

Payment Engine Integration

Prerequisites

You connect external systems through proxy or application programming interfaces (APIs) that require
implementation of Business Add-Ins (BAdIs).

 Note

Payment Engine provides a proxy interface infrastructure and a number of BAdIs for external connection
implementations.

Process

1. You implement the following connection options through interfaces using BAdIs for your specific
applications:
• Connection to account-management systems through a proxy interface
For more information, see Connection to an Account Management System [page 166].
• Connection to an embargo or other system through an API
For more information, see Connection to an Embargo System [page 170].
• Connections to other systems and customer-specific or country-specific extensions by using these
BAdIs as models
2. You implement your specific methods using the BAdI models.
3. You carry out applicable activities in Customizing for Payment Engine.

Payment Engine (FS-PE)

154 PUBLIC Connection of Internal and External Systems
4. You use BAPIs and RFCs to communicate with the connected system.

The figure below illustrates the implementation of extensions and interfaces using BAPIs and RFCs over the
NetWeaver platform.

Payment Engine Extensions and Interfaces

11.1 Enterprise Services for Payment Engine

Use

Payment Engine (FS-PE) can communicate through Enterprise Services from service-oriented architecture
(SOA).

Instead of using file-based payment data channels to communicate between the feeder or forwarding systems
and Payment Engine (FS-PE), you can use the Payment Transaction Processing process component from
Enterprise Services to communicate with other banking process components. This is enabled by the PI
messages defined in the Enterprise Services Repository.

The Payment Transaction Processing process component is in the deployment unit for Payment Transaction
Management. This process component is a central component in transaction banking, and is responsible for
the execution, routing, and clearing of payment transactions. The process component handles services for
incoming and outgoing payment transactions of banks and other financial institutions.

The Payment Transaction Processing process component is related to the following process components,
which request the processing of payment data:

• Bank Account Contract Processing

• Bank Master Contract Processing
• Bank Payment Distribution Processing

The Payment Transaction Order business object plays a central role in this process. Service operations that are
allocated to an appropriate service interfaces request, create, and post payment transaction orders.

Payment Engine (FS-PE)

Connection of Internal and External Systems PUBLIC 155
More Information

Payment Transaction Processing

Payment Transaction Order

11.1.1 Application Management Framework

The Application Management Framework (AMF) provides a technical means for processing and
communication with/in internal and external systems.

Local Application Management Systems represent concrete implementations within the AMF for a defined
processing step, denoted as Application Category.

Example of application categories are:

• System for Liquidity Management

• Charge processing
• FX handling
• FX rate handling

A set of predefined Local Application Management Systems is shipped with SAP Payment Engine Customizing
( Payment Engine Basic Settings Local Application Management Systems ).

Local Application Management System Areas

In order to use a Local Application Management System process, you need to a configure one or more Local
Application Management System Areas.

Local Application Management Areas are variants of Local Application Management Systems with a set of
parameter values.

In each Local Application Management Area, you can define the following:

• Parameters that are specific to the corresponding Local Application Management System;
For example:
• For Liquidity Management, you can enter the RFC destination as a local area attribute.
• For charge processing, you can enter a reference Local Application Management Area used for charge
requests (if charge requests are required).
• An Alternative Local Application Area ID, which is used a fallback if this Local Application Management Area
is not applicable;

Related Information

Charges [page 192]

Payment Engine (FS-PE)

156 PUBLIC Connection of Internal and External Systems
11.1.2 Payment Transaction Order In/Event Out

Use

Payment Engine provides a new online interface for payment orders.

More Information

• Payment Transaction Order In [page 158]

• Payment Transaction Order Event Out [page 162]

11.1.2.1 Payment Transaction Order In

Definition

An interface to handle payment orders synchronously.

Technical Data

Entity Type Service Interface

Namespace

Application Component

Web Service Definition

Category B2B, B2C

Direction Inbound

P2P Communication Enabled

Business Context and Use

This service interface groups operations that create, read, update, and cancel payment transaction orders. A
payment transaction order is a request containing instructions to a bank to carry out payment transactions,
such as a bank transfer or a direct debit. The bank account of the payment initiator can be either debited or
credited depending on the type of the payment.

Related Interfaces

• ManagePaymentTransactionOrderIn containing relevant operations for creation, update and retrieval

• QueryPaymentTransactionOrderIn containing the operation to search for specific payment orders based on
further characteristics

Payment Engine (FS-PE)

Connection of Internal and External Systems PUBLIC 157
• PaymentTransactionOrderActionIn containing the operation for order cancellation and transaction recall

More Information

Payment Transaction Order business object

Payment Transaction Processing processing component

11.1.2.1.1 Managing Payment Transaction Order

Use

You can maintain a payment transaction order for a single payment transaction. It starts to immediately
validate the payment order using the configuration of the E&V (see Enrichment and Validation (FS-PE-EV)
[page 311]). The validation result is returned synchronously.

Technical Data

Entity Type Service Operation

Release State Not defined

Technical Name PaymentTransactionProcessingManagePaymentTransactio-

nOrderIn

Mode Synchronous

Idempotency Not applicable

Change/Update Behavior Not applicable

Business Context and Use

This service manages a single payment transaction in a bank payment system and thus starts the payment
transaction process.

Related Operations

1. The CreateOrder inbound operation receives a request of a sending system to create a payment order.
The payment order is processed according to the Customizing for Payment Engine under File Handler
Financial Message Service Integration Control Payment Order Process .
It provides multiple operations:
• Create only: Processing of the order is done in batch (see Payment Processing (FS-PE-POP) [page
309].
• Validation: The created order is validated according to the application component E&V (Enrichment
and Validation (FS-PE-EV) [page 311].

Payment Engine (FS-PE)

158 PUBLIC Connection of Internal and External Systems
 • Delayed Processing: The order processing is started immediately after the service call has finished.
The processing follows the steps described in Payment Processing (FS-PE-POP) [page 309].
• Immediate Processing: The order is processed synchronously according to Payment Processing (FS-
PE-POP) [page 309] before the service returns its response.
2. The CheckOrderCreation verifies the correct creation of an earlier CreateOrder request using its external
attributes.
3. The RetrieveOrder returns the created order based on its provided internal ID (see CreateOrder).
4. The CheckOrderUpdate verifies if a requested change of the order or an individual transaction is still
possible.
5. The UpdateOrder allows changes to existing transactions as well as the addition or cancellation of
transactions as long as the order has not reached its processing state. Additionally, the order processing is
triggered according to the rules of the CreateOrder service operation.

Error Handling

For information about error handling in Financial Services Transaction Banking, see Error Handling in Financial
Services.

Forward Error Handling

The Create Payment Transaction Order service operation supports forward error handling (FEH).

Message Types

• PaymentTransactionOrderFSCreateRequest
• PaymentTransactionOrderFSByIDResponse
• PaymentTransactionOrderFSCheckCreateQuery
• PaymentTransactionOrderFSCheckCreateResponse
• PaymentTransactionOrderFSUpdateRequest
• PaymentTransactionOrderFSCheckUpdateQuery

Implementation Considerations

Enhancements:

Each operation supports customer additions by using BAdIs.

The BAdI for CreatePaymentTransactionOrder (/PE1/BN__IN_CRT_PYM_ORD_SYNC) Business Add-In (BAdI)

is available for the Create Payment Transaction Order inbound service operation in Customizing for Payment
Engine under BAdIs for Enterprise Services BAdIs for Business Object PaymentTransactionOrder BAdI for
PaymentTransactionProcessingManagePaymentTransactionOrderIn .

For more information, see the BAdI documentation.

More Information

For more information, see the Payment Transaction Order business object and the Payment Transaction
Processing processing component.

Payment Engine (FS-PE)

Connection of Internal and External Systems PUBLIC 159
11.1.2.1.2 Action Payment Transaction Order

Use

You can cancel a payment transaction order or a single transaction based on its business identifier ID. The
object is returned synchronously.

Technical Data

Entity Type Service Operation

Release State Not defined

Technical Name PaymentTransactionProcessingPaymentTransactionOrder-

ActionIn

Mode Synchronous

Idempotency Not applicable

Change/Update Behavior Not applicable

Business Context and Use

This service creates a recall for the requested payment transaction and returns the payment transaction from
a bank payment system. Thus, it can be used for UI integration and B2B integration.

Related Operation

The RecallOrder inbound operation receives a request to cancel the order or an individual transaction of an
order identified by its service identifier ID.

Message Types

• PaymentTransactionOrderFSRecallRequest
• PaymentTransactionOrderFSRecallConfirmation

Implementation Considerations

Enhancements

The recall operation supports customer additions using a BAdI. You find the BAdI for
RecallOrder (/PE1/BN__IN_REC_PYM_ORD_SYNC) Business Add-In (BAdI) for the RecallOrder
inbound service operation in Customizing for Payment Engine under Basic Settings
BAdIs for Enterprise Services BAdIs for Business Object PaymentTransactionOrder BAdI for
PaymentTransactionProcessingPaymentTransactionOrderActionIn .

For more information, see the BAdI documentation.

Payment Engine (FS-PE)

160 PUBLIC Connection of Internal and External Systems
More Information

For more information, see the Payment Transaction Order business object.

11.1.2.1.3 Query Payment Transaction Order

Use

You can search for payment transaction orders based on order and/or item attributes. The resulting match list
is returned synchronously.

Technical Data

Entity Type Service Operation

Release State Not defined

Technical Name PaymentTransactionProcessingQueryPaymentTransactio-

nOrderIn

Mode Synchronous

Idempotency Not applicable

Change/Update Behavior Not applicable

Business Context and Use

This service returns multiple payment transactions in a bank payment system and thus can be used for UI
integration.

Related Operation

The FindOrderByElements inbound operation receives a request to identify one or multiple payment orders by
attributes or order and transaction level.

Message Types

• PaymentTransactionOrderFSByElementsQuery
• PaymentTransactionOrderFSByElementsResponse

Implementation Considerations

The query operation supports customer additions using a BAdI. The BAdI for FindOrderByElements
(/PE1/BN__IN_FND_PYM_ORD_SYNC) Business Add-In (BAdI) for the FindOrderByElements
inbound service operation in Customizing for Payment Engine under Basic Settings

Payment Engine (FS-PE)

Connection of Internal and External Systems PUBLIC 161
 BAdIs for Enterprise Services BAdIs for Business Object PaymentTransactionOrder BAdI for
PaymentTransactionProcessingQueryPaymentTransactionOrderIn .

For more information, see the BAdI documentation.

More Information

For more information, see the Payment Transaction Order business object.

11.1.2.2 Payment Transaction Order Event Out

You can return the processing result of an earlier PaymentTransactionOrderIn-CreateOrder request. If requested
the synchronous order services can trigger a status notification once the order is completely processed.

Technical Data

Entity Type Service Operation

Release State Not defined

Technical Name PaymentTransactionProcessingPaymentTransactionOrderE-

ventOut

Mode Synchronous

Idempotency Not applicable

Change/Update Behavior Not applicable

Business Context and Use

This operation creates a single payment transaction in a bank payment system and thus starts the payment
transaction process.

Related Operations:

• The NotifyOfOrderStatusAsBulk outbound operation returns the processing result once an order is
completely processed.

Payment Engine (FS-PE)

162 PUBLIC Connection of Internal and External Systems
Message Types

• PaymentTransactionOrderFSStatusBulkNotification

11.1.2.3 Payment Transaction Order In

New Service 9.0

11.1.2.4 Payment Transaction Order Out

11.1.3 Payment Engine Connector

Use

SAP Payment Engine provides an online interface for free format messages leveraging the transformation
capabilities of the file handler.

The PaymentTransactionMessage is classified by two fields:

• ContentTypeCode representing a freely defined code which is used to derive the Payment Engine converter
ID
• ContentText representing the abstract data content in any format. XML content has to be encoded, for
example, in Base64 to avoid service validation errors

More Information

Payment Connector In [page 164]

Payment Connector Out [page 165]

File Handler (FS-PE-FH) [page 289]

Payment Engine (FS-PE)

Connection of Internal and External Systems PUBLIC 163
11.1.3.1 Payment Connector In

Use

You can transfer any data content to the inbound file handler framework.

Activities

An appropriate inbound converter is determined. It executes the conversion process automatically based
on Customizing for Payment Engine under File Handler Financial Message Service Integration Assign
Converter IDs to Free Message Types (Inbound) .

In addition the BAdI: Free Message Integration (/PE1/BADI_MSG_INTV1) is available to control the processing
of the created business objects, for example, payment order, recall or request agent and update the free format
response code and content tag.

A default implementation is available. It processes the objects according to the following rules. If automatic
processing is active for the ContentTypeCode in Customizing for Payment Engine under File Handler
Financial Message Service Integration Assign Converter IDs to Free Message Types (Inbound) :

• Request agents are not processed automatically. Use batch processing. For more information, see Request
Agent [page 150].
• Recalls are automatically activated and processed according to the Recall Transaction Order In rules.
• Payment orders are processed according to the rules of Payment Transaction Order In service operation,
which is controlled by in Customizing for Payment Engine under File Handler Financial Message
Service Integration Control Payment Order Process

The result of the import step is returned synchronously containing the import ID (object list) and its processing
status. In addition the BAdI:Free Message Integration is available to populate a free format response (content
type code and content text).

Technical Data

Entity Type Service Operation

Release State Not defined

Technical Name PaymentTransactionProcessingManagePaymentTransactio-

nOrderIn

Mode Synchronous

Idempotency Applicable

Change/Update Behavior Not applicable

Direction Inbound

BAdI /PE1/BADI_MSG_INTV1

Business Context and Use

Payment Engine (FS-PE)

164 PUBLIC Connection of Internal and External Systems
This operation receives a single payment message that can be sent from a corporate customer, an internal
application, or an external bank. The import and optional processing response is returned synchronously and
thus supports real-time processing interfaces such as ISO 8583 card transactions (also see Card Transaction
Processing [page 125]).

Related Operation

The CreateMessage inbound operation receives a request from a sending system to import a free format
message.

Message Types

• PaymentTransactionMessageFSCreateRequest
• PaymentTransactionMessageFSCreateConfirmation

Implementation Considerations

Enhancements:

The BAdI:Free Message Integration (/PE1/BADI_MSG_INTV1) is available for the CreateMessage inbound
service operation in Payment Engine under Basic Settings BAdIs for Enterprise Services BAdIs for
Business Object PaymentTransactionMessage BAdI for Free Message Integration .

For more information, see the system BAdI documentation.

More Information

Payment Transaction Order business object and the Payment Transaction Processing processing component.

11.1.3.2 Payment Connector Out

You can transfer any data content, for example, from the outbound file handler framework to a message
receiver and receive synchronous processing response.

Technical Data

Entity Type Service Operation

Release State Not defined

Technical Name PaymentTransactionConnectorManagePaymentTransactionMess

ageOut

Mode Synchronous

Payment Engine (FS-PE)

Connection of Internal and External Systems PUBLIC 165
Idempotency Not applicable

Change/Update Behavior Not applicable

Direction Outgoing

BAdI /PE1/BN__OUT_CRT_FREE_MSG

Business Context and Use

This operation sends a single payment message, which can send an advise to a corporate customer, an internal
application, or a payment file to an external bank and receives a synchronous response. Thus, this operation
can be used for real-time processing integration.

Related Operation

The CreateMessage outbound operation to send a request to a sending system in a free format message.

Message Types

• PaymentTransactionMessageFSCreateRequest
• PaymentTransactionMessageFSCreateConfirmation

Implementation Consideration

Enhancements:

The Business Add-In BAdI:Create Outbound Free Message (/PE1/BN__OUT_CRT_FREE_MSG) is available for
the CreateMessage service operation in Payment Engine under Basic Settings BAdIs for Enterprise Services
BAdIs for Business Object PaymentTransactionMessage BAdI for Create Message Out .

For more information, see the BAdI documentation.

11.2 Connection to an Account Management System

Use

You can connect Payment Engine to an available account management system (AMS) through the Account
Management (AM) Proxy. The AM Proxy is an interface between the Clearing Processing component and a
connected AMS. It is used to map information and error codes.

Payment Engine (FS-PE)

166 PUBLIC Connection of Internal and External Systems
Account management systems are systems to which Payment Engine connects in order to make postings.
The postings made to these systems are internal, as opposed to external postings and are prepared in the
form of outgoing payment orders that pass through the File Handler. Account Management (FS-AM) and Bank
Customer Accounts (IS-B-BCA) are examples of SAP account management systems.

Prerequisites

• You have defined the account management system (AMS) and AM areas in Customizing for Payment
Engine under Basic Settings Account Management Systems :
• Define Account Management Systems
• Define Account Management Areas
• Define SAP AM Bank Posting Area
• You have implemented methods for configuring customer-specific changes to the payment items for an
AMS in Customizing for Payment Engine under Basic Settings Account Management Systems BAdI:
Customer-Specific Change of Payment Items (AM) .
• You have set up the AM Proxy in Customizing for Payment Engine under Posting Interfaces DM Proxy
[or] BCA Proxy by maintaining:
• Clearing areas, actions, and communication data under Basic Settings
• Posting definitions under Posting
• Response definitions and error codes under Response
• You have mapped payment items to AM items in Customizing for Payment Engine under Posting
Interfaces DM Proxy [or] BCA Proxy Business Add-Ins (BAdIs) .

Features

Proxy Interface Infrastructure

Communication takes place through remote functions calls (RFCs) from Payment Engine to the Business
Application Programming Interfaces (BAPIs) of the connected AMS. The system uses RFCs for the collection
of pending posting responses from the AMS and BAPIs for the reservation and posting of items. It uses
asynchronous processing of items when the connection is temporarily not available.

 Note

You can use the proxy interface infrastructure to connect further account management systems to
Payment Engine by modeling your implementations on this process.

You can also use enterprise services for communication between Payment Engine and an AMS. For more
information, see Enterprise Services for Payment Engine [page 155].

Integration of Account Management (FS-AM)

For information, see Account Management Proxy (FS-PE-AMP) [page 364].

Integration of Bank Customer Accounts (IS-B-BCA)

Payment Engine (FS-PE)

Connection of Internal and External Systems PUBLIC 167
You can connect Bank Customer Accounts (IS-B-BCA) as an account management system to Payment Engine
to be able to transfer external postings from Bank Customer Accounts (IS-B-BCA) to Payment Engine. It is then
possible to perform the following tasks:

• Post items or simulate posting from Payment Engine to Bank Customer Accounts (IS-B-BCA)
• Reserve items in BCA
• Store asynchronous posting responses in BCA
• Process asynchronous BCA posting responses in Payment Engine
• Set up report-based reconciliation with BCA
For information, see SAP Note 1860880 .

For more information, see Account Management Proxy (FS-PE-AMP) [page 364].

More Information

Clearing Processing (FS-PE-CP) [page 337]

11.3 FI Integration

Use

You can connect Payment Engine to an SAP ERP Financials (FI) system to enable postings from Payment
Engine to this FI system, that is, to create FI documents on a G/L account.

Prerequisites

SAP delivers an FI proxy class. To use this proxy class, perform the following Customizing activities:

• Define the FI proxy settings in Customizing for Payment Engine under Posting Interfaces FI Proxy as
follows:
• Determine whether posting dates should be transferred in the Customizing activity Maintain Transfer
of Posting Date.
• Create and define a G/L account in the Customizing activity Define G/L Accounts.
• Create and define a G/L variant in the Customizing activity Define G/L Variants.
• Create and define an account symbol in the Customizing activity Define Account Symbols for G/L
Accounts.
• Assign a Payment Engine transaction type to an account symbol in the Customizing activity Assign PE
Trans.Types to Account Symbols.
• Create an RFC connection to an SAP ERP Financials system in Customizing for Payment Engine under
Basic Settings Account Management Systems as follows.

Payment Engine (FS-PE)

168 PUBLIC Connection of Internal and External Systems
 • Define an account management system for the FI proxy in the Customizing activity Define Account
Management Systems.
• Create an account management area for a clearing area and define the attributes for the RFC
connection in the Customizing activity Define Account Management Areas.

Integration

During routing, the system determines an FI account management area based on the master data and uses the
FI proxy to post a payment item from Payment Engine to SAP ERP and then create an FI document.

You can view the FI document in SAP ERP using transaction FB03.

11.4 CML Integration

Use

You can integrate Payment Engine with Consumer and Mortgages Loans (CML) in SAP ERP. The converters
used for CML integration are based on the XML format converter framework.

Integration

The integration of Payment Engine with Consumer and Mortgages Loans (CML) supports the following
scenarios:

• Credit transfer from CML to Payment Engine.

• The SAP ERP payment program F110 has to use the Data Medium Exchange Engine (DMEE) format
tree SEPA_CT_CML_DATA to generate a payment file for credit transfers.
• The generated file has to be imported into Payment Engine by using the XML converter with message
identifier /CMLINT_CT.
• The file import generates a payment order that is processed by Payment Engine.
• Direct debit from CML to Payment Engine.
• The SAP ERP payment program F110 has to use the DMEE format tree SEPA_DD_CML_DATA to
generate a payment file for direct debits.
• The generated file has to be imported into Payment Engine by using the XML converter with message
identifier /CMLINT_DD.
• The file import generates a payment order that is processed by Payment Engine.
• Return of credit transfer from CML to Payment Engine
• The SAP ERP payment program F110 has to use the DMEE format tree SEPA_CT_CML_RETURN to
generate a payment file for the return of credit transfers.
• The generated file has to be imported into Payment Engine by using the XML converter with message
identifier /CMLINT_CT_RET.

Payment Engine (FS-PE)

Connection of Internal and External Systems PUBLIC 169
 • The file import generates a payment order that is processed in Payment Engine.
• Transfer payment information from Payment Engine to CML
1. Payment Engine receives a payment file, for example, from clearing institute. The recipient items are to
be forwarded to CML.
2. The recipient items are collected in an internal collector. The XML converter with /CMLINT_CAMT054
must be assigned to the corresponding clearing agreement.
3. The output converter generates a camt.054 message.
4. The camt.054 message is imported by the ERP electronic bank payment transaction, which then posts
the items to the CML account.

Activities

• You set up the mapping rules for the SEPA format converter in Customizing for Payment Engine under
File Handler SEPA Format Converter .
• The format converter for the return scenario is linked to the process integration converter. For this reason,
you define mapping rules in Customizing for Payment Engine under File Handler Process Integration
Format Converter .

11.5 Connection to an Embargo System

Use

You can connect Payment Engine to an available external embargo system to check embargo-relevant payment
data that you send to an embargo system for processing.

Payment Engine enables synchronous communication through customer Business Add-Ins (BAdIs) and
asynchronous communication through Business Application Programming Interfaces (BAPIs).

Prerequisites

• You have implemented your specific methods in Customizing for Payment Engine under Payment Order
Business Add-Ins (BAdIs)
• BAdI: Implementation of User Methods for Payment Order
• BAdI: Implementation of User Methods for Payment Item
• You have defined embargo system responses that determine whether payment items require exception
handling and you have mapped these responses to Payment Engine responses. You do this in Customizing
for Payment Engine under Embargo Management:
• Maintain Embargo Response Codes

Payment Engine (FS-PE)

170 PUBLIC Connection of Internal and External Systems
 • Maintain for Embargo Response Code Mapping

Features

 Note

You can use the available interface infrastructure to connect further external systems to Payment Engine by
modeling your implementations on this process.

More Information

Embargo Check [page 333]

For more information about security, see Administrator's Guide for SAP Payment Engine

11.6 Connection to a Liquidity Management System

You can connect SAP Payment Engine to the internal liquidity management or to an external system (SAP or
non-SAP), for example, SAP Cash and Liquidity Management. You connect the internal and external liquidity
management system through a proxy.

During enrichment and validation, depending on your configuration, you can send notifications for incoming or
outgoing payments.

Prerequisites

• You have performed the Customizing for Payment Engine under Basic Settings Local Application
Management Systems Define Local Application Management Systems . You can use the default
class /PE1/CL_APP_LIQUIDITY or create your own class instead.
• You have performed the Customizing for Payment Engine under Basic Settings Local Application
Management Systems Define Local Application Management Areas .
• You have defined the rules for the notification to be sent to the liquidity management system. You do this
in Customizing for Payment Engine under Payment Order Payment Order Enrichment and Validation
Check Specific Configuration Maintain Rules for Liquidity process .
• To transfer the liquidity information, you can create an RFC connection or use a file-based approach for the
internal or external system.

Payment Engine (FS-PE)

Connection of Internal and External Systems PUBLIC 171
12 Referential Data Interface (FS-PE-RDI)

Use

You use this component to upload referential data made available by external data providers to Payment Engine
and to manage this data. Payment Engine supports the upload of:

• Routing directory data

• Standard settlement instructions (SSI)
• Bank master data

Implementation Considerations

Referential data is essential in enrichment and validation and in the management of the routing process and
clearing agreement areas. It increases straight-through-processing (STP) rates.

Features

You can process referential data in the following ways:

• Upload referential data in a file

On the SAP Easy Access screen, choose Payment Engine Referential Data Upload Referential Data
(transaction /PE1/UPLOAD_RD). For more information, see:
• Upload of Referential Data [page 174]
• Upload of Referential Data (SSI) [page 178]
• Upload of Referential Data (Bank Master Data) [page 181]
• Map provider-dependent referential data to a generic data structure and store the data in Payment Engine
• Validate the structure of referential data uploaded to Payment Engine
• Display and edit referential data
On the SAP Easy Access screen, choose Payment Engine Referential Data :
• Routing Directory Manage Routing Directory Data (transaction /PE1/MN_ROUTDIR)
• Standard Settlement Instructions (SSI) Manage Standard Settlement Instructions (SSI)
(transaction /PE1/MN_SSI)
• Bank Master Data Manage Master Data (transaction /PE1/MN_BNKSTRUCT)
• Display change documents for referential data records
• Generate business partner data for every bank master data record. For more information, see Business
Partner Generation (Offline) [page 183].
• Display business partners

Payment Engine (FS-PE)

172 PUBLIC Referential Data Interface (FS-PE-RDI)
 On the SAP Easy Access screen, choose Payment Engine Referential Data Bank Master Data
Display Business Partners (transaction /PECROSS/BP_BANK).
• Determine the payment transaction chain used during straight-through processing (STP) of in cross-
border payments based on standard settlement instructions (SSI)
• Validate IBANs and IBAN-BIC combinations, for example, to ensure that a BIC and an IBAN belong to the
same financial institution
• Derive the BIC of a financial institution from an IBAN, for example, if the IBAN is present but the BIC is
missing or not valid in a payment instruction

 Note

The system retrieves the country code and the national ID from the IBAN and uses these attributes
to search in the SAP Bank Directory. As a result, the matching BIC and branch code are returned.
However, the system cannot derive a BIC from an IBAN if a financial institution issues different BICs to
accounts, but issues IBANs containing the same national ID.

More Information

Routing Directory [page 173]

Standard Settlement Instructions (SSI) [page 176]

Bank Master Data [page 180]

12.1 Routing Directory

Definition

A collection of data that lists financial institutions and the related bank identifier codes (BIC) that are eligible
for processing payment instructions. The data is transmitted in files that are structured in accordance with the
specifications of the data provider.

Use

You use routing directories, also known as routing tables, to upload and manage routing data. Payment Engine
uses this data during the routing process to route payment transactions to financial institutions that are eligible
to execute payment transactions using a specified clearing system, for example, the STEP2 system of the Euro
Banking Association (EBA). The routing directory data also enables Payment Engine to determine whether a
financial institution can execute payment transactions under a specific service level, for example, the Single
Euro Payments Area (SEPA), and for a specific scheme, for example, a SEPA Credit Transfer (SCT).

Payment Engine (FS-PE)

Referential Data Interface (FS-PE-RDI) PUBLIC 173
Structure

A routing directory record contains the following data:

• UUID
• Bank identifier code (BIC)
• Service level
• Payment scheme
• Status of the direct participant
• Clearing system ID and whether the system is the preferred clearing system of the financial institution for
receiving payment instructions
• Reachable type
• Settlement BIC
• Admission profile
• Activation date and deactivation date
• Record key

The record indicates whether the data has been manually changed.

Integration

You upload routing information from an external file. For more information, see Upload of Referential Data
[page 174]. The system maps the information to a generic data structure defined in Payment Engine. You
can access the stored data on the SAP Easy Access screen by choosing Payment Engine Referential Data
Routing Directory Manage Routing Directory Data (transaction /PE1/MN_ROUTDIR). During the routing
process, this data is used to route payment transactions to eligible financial institutions.

More Information

Routing Control (FS-PE-RP) [page 205]

12.1.1 Upload of Referential Data

Use

You use this report to upload external routing data provided by a financial association or cooperative such as
the Euro Banking Association (EBA) in a file with a standardized data structure.

Payment Engine (FS-PE)

174 PUBLIC Referential Data Interface (FS-PE-RDI)
Prerequisites

• You have obtained the most recent routing data from the data provider, for example, EBA.
• You have saved the file containing the referential data on the server from where you want to upload the file.
• You have defined clearing system IDs in Customizing for Payment Engine under File Handler Basic
Settings Maintain Clearing System Identifications .
• You have implemented the Business Add-In BAdI: Retrieval of Clearing Systems in Customizing for
Payment Engine under Referential Data Routing Directory BAdI: Retrieval of Clearing Systems .

 Note

Routing directory records contain a clearing system ID and whether the clearing system is the
preferred clearing system of the financial institution for receiving payment instructions.

Features

This report uploads the data records for a specific data model in a file provided by an external data provider.
The system validates the data structure. If the data structure is correct, the system maps the data records to
the data structure defined in Payment Engine and stores the data records in a database that you can access to
display, check, and change data records.

Selection

Referential data

• Data model
• Data provider

Upload process

• Delta upload
• Maximum package size
• Test

File location

You specify the path and the name of the referential data file to be uploaded from an application server or a
presentation server.

Output

The uploaded data is mapped to the database internal data structure. For information about the data structure,
see Routing Directory [page 173].

Activities

• To access this report, on the SAP Easy Access screen, choose Payment Engine Referential Data
Upload Referential Data (transaction /PE1/UPLOAD_RD).

Payment Engine (FS-PE)

Referential Data Interface (FS-PE-RDI) PUBLIC 175
• To display, check, and, if necessary, change the data in the routing directory records you uploaded, on
the SAP Easy Access screen choose Payment Engine Referential Data Routing Directory Manage
Routing Directory Data (transaction /PE1/MN_ROUTDIR).

Example

Full Upload

You want to upload a file that is based on the SEPA data model that contains routing information related to
financial institutions that participate directly in the SEPA Direct Debits (SDD) payment scheme. In Data Model,
you choose SDD direct. You obtained the file from the Euro Banking Association, so in Data Provider, you
choose EBA.

The database contains no routing data and the file contains a large number of data records. In Max. Package
Size, you enter 3000 to reduce the number of data records that the system processes. The system splits the
total number of records into smaller packages and then repeats the uploading process for all packages until all
packages have been processed.

More Information

Referential Data Interface (FS-PE-RDI) [page 172]

12.2 Standard Settlement Instructions

Definition

Payment processing and settlement information such as bank account details for a specific currency and
payment category to be used for a financial institution. The financial institution specifies this information.

Use

The system uses standard settlement instructions to determine the financial institutions that are involved
in cross-border payments and support correspondent banking scenarios. For example, standard settlement
instructions contain information about the intermediary financial institutions used by the ordering and
receiving financial institutions.

Payment Engine (FS-PE)

176 PUBLIC Referential Data Interface (FS-PE-RDI)
Structure

A record of standard settlement instructions contains the following data:

• Record key
• Operational BIC
• ISO currency code
• Payment category
• ALL: All Types of Payments
• COM: Commercial\Retail\Customer Payments
• FIN: All Interbank Wholesale Payments
• Holder BIC
• Clearer BIC
• Whether the record for standard settlement instructions is preferred by the owner of the standard
settlement instructions for the same currency
• Activation date and deactivation date

The record also indicates whether the data has been manually changed.

Integration

You upload information for standard settlement instructions from an external file. For more information, see
Upload of Referential Data [page 178]. The system maps the information to a generic data structure defined
in Payment Engine (FS-PE). You can access the stored data on the SAP Easy Access screen by choosing
Payment Engine (FS-PE) Referential Data Standard Settlement Instructions (SSI) Manage Standard
Settlement Instructions (SSI) (transaction /PE1/MN_SSI).

During the enrichment and validation process, the information of the standard settlement instructions is used
to determine the financial institutions used in the transaction chain of cross-border payments. The data related
to these financial institutions is enriched in accordance with the Payment Engine (FS-PE) metaformat of the
payment item. The system can enrich the data of intermediary institutions and receiving institutions. For more
information about enrichment and validation, see Enrichment and Validation [page 311]. If the transaction
chain cannot be determined completely, exception handling is triggered. For more information about exception
handling, see Exception Control (FS-PE-EH) [page 265].

More Information

Cross-Border Payment Processing [page 103]

Payment Engine (FS-PE)

Referential Data Interface (FS-PE-RDI) PUBLIC 177
12.2.1 Upload of Referential Data (Standard Settlement
Instructions)

Use

You use this report to upload the standard settlement instructions (SSI) of financial institutions such as in a file
with a standardized data structure provided by a payment data provider such as Accuity

Prerequisites

• You have obtained the most recent information of the standard settlement instructions from the data
provider, for example, Accuity.
• You have saved the file containing the information of the standard settlement instructions on the server
from where you want to upload the file.
• You have defined the priority of attributes that the system uses to determine the best matched transaction
chain for standard settlement instructions. You have done this in Customizing for Payment Engine (FS-
PE) by choosing Referential Data Standard Settlement Instructions (SSI) Define the Priority of SSI
Attributes .

Features

This report uploads the data records for a specific data model in a file provided by an external data provider.
The system validates the data structure. If the data structure is correct, the system maps the data records to
the data structure defined in Payment Engine (FS-PE) and stores the data records in a database that you can
access to display, check, and change data records.

Selection

Referential data

• Data model
• Data provider

Upload process

• Delta upload
• Maximum package size
• Test

File location

You specify the path and the name of the referential data file to be uploaded from an application server or a
presentation server.

Output

Payment Engine (FS-PE)

178 PUBLIC Referential Data Interface (FS-PE-RDI)
The uploaded data is mapped to the database internal data structure. For information about the data structure,
see Standard Settlement Instructions [page 176].

Activities

• To access this report, on the SAP Easy Access screen, choose Payment Engine (FS-PE) Referential
Data Upload Referential Data (transaction /PE1/UPLOAD_RD).
• To display, check, and, if necessary, change the data in the routing directory records you uploaded, on
the SAP Easy Access screen choose Payment Engine (FS-PE) Referential Data Standard Settlement
Instructions (SSI) Manage Standard Settlement Instructions (SSI) (transaction /PECROSS/MN_SSI).

Example

Full Upload

You want to upload a file that contains the settlement data of financial institutions that use the CB.Net service
of Accuity to distribute their standard settlement instructions. In Data Model, you choose SSI. In Data Provider,
you choose CB.Net.

The database contains no data for standard settlement instructions and the file contains a large number of
data records. In Max. Package Size, you enter 3000 to reduce the number of data records to be processed
simultaneously. The system repeat the process until all records have been uploaded

Delta Upload

You want to upload a file that contains the settlement data of financial institutions that use the CB.Net service
to distribute their standard settlement instructions. In Data Model, you choose SSI. In Data Provider, you
choose CB.Net.

The database already contains data records and you only want to update the database with new or changed
data records. You choose Delta Upload to upload only updated data records to reduce the upload time.

More Information

Referential Data Interface (FS-PE-RDI) [page 172]

Payment Engine (FS-PE)

Referential Data Interface (FS-PE-RDI) PUBLIC 179
12.3 Bank Master Data

Definition

Reference information about a financial institution that is required to conduct business transactions with this
financial institution, such as the institution’s contact information, offices and branches, clearing codes such as
BIC, and domestic clearing codes.

Use

Bank master data uniquely identifies financial institutions. You upload bank master data provided by external
data sources that the system uses to validate payment information, for example, bank identifier codes (BIC)
and national IDs, and to support straight-through processing (STP) of cross-border payments.

Structure

A bank master data record contains the following data:

• Record ID
• Name of the financial institution (maximum four lines)
• Bank identifier code (BIC)
• BIC associated with the routing account national ID and its expiry date
• Identification or account number of the US Clearing House Interbank Payments System (CHIPS)
• Nonformatted address of the financial institution (maximum four lines)
• Address of the financial institution (street, house number, country, postal code, city, post office box
information)
• Telephone number
• Fax number
• E-mail address
• Web site URL
• Head office record ID
• Date on which the record was last updated
• Activation date and deactivation date

The record indicates whether the data has been manually changed.

Integration

You upload bank master data from an external file. For more information, see Upload of Referential Data
(Bank Master Data) [page 181]. You can access the stored data on the SAP Easy Access screen by choosing

Payment Engine (FS-PE)

180 PUBLIC Referential Data Interface (FS-PE-RDI)
 Payment Engine Referential Data Bank Master Data Manage Bank Master Data (transaction /PE1/
MN_BNKSTRUCT).

 Note

When you manage bank master data records in this table, up to 250,000 records can exist. Therefore, you
manage the records by country to reduce the number of records that the system displays.

For every bank master data record, you can create a business partner with the business partner role Bank. For
more information, see Business Partner Generation (Offline) [page 183].

More Information

Cross-Border Payment Processing [page 103]

12.3.1 Upload of Referential Data (Bank Master Data)

Use

You use this report to upload external bank master data provided by a financial association or cooperative such
as SWIFT in a file with a standardized data structure.

Prerequisites

• You have obtained the most recent bank master data from the data provider, for example, SWIFT.
• You have saved the file containing the bank master data on the server from where you want to upload the
file, for example, a BICPlusIBAN file.

Features

This report uploads the data records for a specific data model in a file provided by an external data provider.
The system validates the data structure. If the data structure is correct, the system maps the data records to
the data structure defined in Payment Engine and stores the data records in a database that you can access to
display, check, and change data records.

Selection

Referential data

• Data model

Payment Engine (FS-PE)

Referential Data Interface (FS-PE-RDI) PUBLIC 181
• Data provider

Upload process

• Delta upload
• Maximum package size
• Test

File location

You specify the path and the name of the referential data file to be uploaded from an application server or a
presentation server.

Output

The uploaded data is mapped to the database internal data structure. For information about the data structure,
see Bank Master Data [page 180].

Activities

• To access this report, on the SAP Easy Access screen, choose Payment Engine Referential Data
Upload Referential Data (transaction /PE1/UPLOAD_RD).
• To display, check, and, if necessary, change the bank master data records you uploaded, on the SAP Easy
Access screen choose Payment Engine Referential Data Bank Master Data Manage Bank Master
Data (transaction /PE1/MN_BNKSTRUCT).

Example

Full Upload

You want to upload a file that contains information (bank master data) related to financial institutions that are
members of SWIFT. In Data Model, you choose Bank Master. In Data Provider, you choose SWIFT.

The database contains no bank master data and the file contains a large number of data records. In Max.
Package Size, you enter 1000 to reduce the number of data records that are uploaded to one thousand. You
repeat the procedure, but also choose Delta Upload to avoid overwriting the data records that you have already
uploaded.

Delta Upload

You want to upload a file that contains information (bank master data) related to financial institutions that are
members of SWIFT. In Data Model, you choose Bank Master. In Data Provider, you choose SWIFT.

The database already contains data records and you only want to update the database with new or changed
data records. You choose Delta Upload to upload only updated data records to reduce the upload time.

Payment Engine (FS-PE)

182 PUBLIC Referential Data Interface (FS-PE-RDI)
More Information

Referential Data Interface (FS-PE-RDI) [page 172]

12.3.2 Business Partner Generation (Offline)

Use

You use this report to create and manage business partner master data for financial institutions using external
bank master data that you upload to Payment Engine in a file.

Integration

This function integrates bank master data with SAP Business Partner.

Prerequisites

You have uploaded the most recent bank master data to Payment Engine. For more information, see Upload of
Referential Data (Bank Master Data) [page 181].

Features

Selection

You can determine the financial institutions for which you generate a business partner by specifying ranges for
the following attributes:

• Country
• Postal Code (Street)
• Record ID
• Bank identifier code (BIC)
• National ID

You specify that one or more of the following actions is to be performed:

• Create new business partners

• Modify existing business partners
• Flag obsolete business partners for archiving

Payment Engine (FS-PE)

Referential Data Interface (FS-PE-RDI) PUBLIC 183
When you want to generate business partner master data using a large number of bank master data records,
you can limit the number of records to be processed by entering a maximum package size. Therefore, you must
generate business partner master data for a large number of bank master data records in more than one batch.

 Note

When you perform a full upload, a file can contain several hundred thousand records.

Output

The system creates a business partner with the business partner role Bank for each bank master data record.

The business partner has the role Bank and contains the following information:

• Name of the financial institution

• Address of the financial institution (only one address)
• The following IDs:
• Bank identifier code (BIC)
• National ID
• BIC associated with the routing account national ID
• Identification or account number of the US Clearing House Interbank Payments System (CHIPS)
• Record ID of the data provider

The system also persists the record ID and the BIC as search term 1 and 2 in the business partner master
records.

Activities

• To access this report, on the SAP Easy Access screen choose Payment Engine Referential Data Bank
Master Data Generate Business Partners (Offline) (transaction /PECROSS/BP_GEN).
• To display business partners on the SAP Easy Access screen choose Payment Engine Referential Data
Bank Master Data Display Business Partners (transaction /PECROSS/BP_BANK).

More Information

Bank Master Data [page 180]

Payment Engine (FS-PE)

184 PUBLIC Referential Data Interface (FS-PE-RDI)
12.4 Account Substitution

Use

You can set up account substitution so that system substitutes account information based on a defined
account substitution rule. You can create rules for an enrichment and validation check by using a BAPI in the
standard system or by using the Manage Account Substitution Data transaction.

 Note

This document describes how to create rules by using the Manage Account Substitution Data transaction.

Prerequisites

You have defined the settings for account substitution. To do this, on the SAP Easy Access screen,
choose Payment Engine Referential Data Account Substitution Manage Account Substitution Data
(transaction /PE1/MN_ACCSUBS).

Features

Matching

So that the system can identify the correct account for substitution, specify one field or a combination of fields:

• IBAN
• BIC and account number
• Bank country, bank key and account number

 Recommendation

You can use the wildcards * and + in the above fields.

However, for performance reasons, we recommend that you limit the amount of entries with wildcards.

You can use the following fields to narrow down the set of matches:

• Referential BIC
• PE Transaction Type
• Bank Country
• Referential Country
• Referential Bank Key
• Referential IBAN
• Account Holder

Payment Engine (FS-PE)

Referential Data Interface (FS-PE-RDI) PUBLIC 185
• Holder of Referential Account
• Transaction Amount from/to
• Remittance Match Code

 Note

• Fields that you do not specify are not included in the matching process.
• When matching according to transaction amount, you must specify a lower limit and an upper limit
with the corresponding currency. Transaction amounts outside that amount interval are excluded from
the match list.
• If you specify a remittance match code, the system scans the remittance of type unstructured
remittance information (/320) of the payment item for the defined pattern.
• Consider adding a preceding and a trailing wildcard (*) for remittance match codes. In this way, the
system will also retrieve longer remittance information that includes the match code. Using wildcards
within the remittance check does not impede performance.

You can specify matching data in addition to account information in the following cases:

• You want payments that are targeted for a specific account to be distributed to a set of accounts according
to further rules (1 : n).
• When you use wildcards and the retrieved substitution data is not unique but should be restricted further
(n : 1).

Retrieval according to specificity

If several matching substitution records, the system selects one record according to the following criteria (with
decreasing precedence):

• Match Code has been specified

• Amount to has been specified
• Preference for higher values of the field sequence number

Check method – activation and implications

The enrichment and validation check method is /PE1/CL_PO_E_EV_CHECK_PI,

CHECK_E_ACC_SUBSTITUTION.

If the system finds a matching account substitution record, the system replaces the account information of the
payment item with (non-initial) substitution fields.

More Information

Ordering Party Item Checks [page 319]

Recipient Item Checks [page 322]

Payment Engine (FS-PE)

186 PUBLIC Referential Data Interface (FS-PE-RDI)
13 Master Data

Use

You can manage the following master data objects in Payment Engine.

• Charge conditions
• Bank file clearing data
• Route and route rule set
• Clearing agreement and clearing agreement rule set
• Request agent bulk assignment
• Customer agreement and customer agreement rule set
• Value date agreement and rule set for value date agreements
• Service level agreement (SLA)

Integration

• You store and manage the financial conditions for payment transaction charges by using the standard
SAP component Financial Conditions (CA-FIM-FCO) or another charge provider. For more information, see
Charges [page 192].
• The system uses bank file clearing data to determine the clearing account of ordering party items for
incoming payments orders. For more information, see Bank File Clearing [page 202].
• The system enhances the payment information (when necessary) and validates it against the various types
of master data, such as the service level agreement (SLA). For more information, see Enrichment and
Validation [page 311] and Service Level Agreement [page 256].
• During route processing, the system determines how to process payments based on the master data
linked to each payment item. For more information see Routing Control (FS-PE-RP) [page 205].
• The master data information stored in Payment Engine for each of these objects is used in the Clearing
Processing component to further process payments. For more information, see Clearing Processing (FS-
PE-CP) [page 337].
• You use exception control rule sets to determine suitable response types for errors that occur during
straight-through processing (STP) and file handling. For more information, see Exception Control (FS-PE-
EH) [page 265].

Features

• Master data objects and business rules are separated at clearing-area level. For more information, see
Clearing Area [page 129].

Payment Engine (FS-PE)

Master Data PUBLIC 187
• Master data objects are linked to each payment through the use of rule sets. For more information, see
Rule Set [page 188].
• All manual changes to master data (or transactional data) that occur within Payment Engine are logged to
change documents that display who changed what and at what time.

More Information

Status and Release Status of Master Data Objects [page 216]

13.1 Rule Set

Definition

A sequence of rules in a defined order.

A rule determines a target business object. A business object can be, for example, a route, a clearing
agreement, or a charge condition.

Use

Rule sets can be defined for the following:

• Bank File Clearing

• Routing Control
Business objects under Routing Control include route, clearing agreement, customer agreement, and value
date agreement.
• Service Level Agreement
Business objects under Service Level Agreements include Instruction Code check (Submission Data),
foreign exchange conditions, charge conditions.
• Exception Control

You can use wildcard characters for all rule set attributes, which offers flexibility to optimize the rules and
serves the business requirements that comprise payment operations. During processing, the system searches
for the appropriate rule and assigns the associated business object to payment items. For more information,
see Business Object Determination Using Rule Sets [page 189].

Payment Engine (FS-PE)

188 PUBLIC Master Data
Structure

A rule set consists of one or more rules. Each rule consists of a set of characteristics based on the payment
order or payment item attributes. These attributes are rule-set specific. A rule matches if the attributes of a
payment order or payment item match the attributes of the rule.

You can display all available attributes in the rule maintenance of the corresponding business object. You can
find details on the attributes of individual rule sets in the topics on managing the respetive rules and rule sets.

Examples of rule set attributes are payment order type, payment item type, amount, and currency. Validity
criteria can restrict the validity timeframe of a rule. The validity timeframe of a rule can be determined using
the time, date, days of the week, and special days. The system validates these validity criteria against the
Payment Engine reconciliation date and reconciliation time.

The rule status indicates whether a rule is active. During business object determination, the system checks
only activated rules.

Integration

An individual rule within a rule set refers to exactly one business object. The same business object can occur in
several rules.

More Information

Bank File Clearing [page 202]

Routing Control (FS-PE-RP) [page 205]

Service Level Agreement [page 256]

Exception Control (FS-PE-EH) [page 265]

13.1.1 Determining Business Objects with Rule Sets

Use

You can manage some Master Data by using rule sets. Rule sets define a target business object, such as a
route, which determine how the payment will be further processed.

To find a business object, a rule-determination process is performed, where each rule is processed sequentially
until the system finds a rule whose conditions are fulfilled completely, or until all rules in a rule set have been
analyzed.

Payment Engine (FS-PE)

Master Data PUBLIC 189
Prerequisites

You have defined the necessary settings in Customizing for Payment Engine.

You have defined rule sets for the corresponding target business objects:

• Rule set for bank file clearing:

On the SAP Easy Access screen, choose Payment Engine Master Data Bank File Clearing Manage
Bank File Clearing Accounts
• Rule sets for routes, clearing agreements, and customer agreements:
On the SAP Easy Access screen, choose Payment Engine Master Data Routing Control Manage
Routes and Clearing Agreements .
• Rule sets for value date agreements:
On the SAP Easy Access screen, choose Payment Engine Master Data Routing Control Manage Set
of Rules for Value Date .
• Rule set for the instruction code check:
On the SAP Easy Access screen, choose Payment Engine Master Data Service Level Agreements
Manage Service Level Agreements Submission Data
• Rule sets for foreign exchange conditions:
On the SAP Easy Access screen, choose Payment Engine Master Data Service Level Agreements
Manage Service Level Agreements Foreign Exchange
• Rule sets for charge conditions:
On the SAP Easy Access screen, choose Payment Engine Master Data Service Level Agreements
Manage Service Level Agreements Charges
• Rule set for exception handlings:
On the SAP Easy Access screen, choose Payment Engine Master Data Exception Control Define
Exception Control

Features

Rule Determination

During processing, the system checks the rules in a rule set. According to the defined sequence in the rule
set, the system checks the payment order and payment item characteristics against all rules of the rule set
starting with the first rule in the sequence. If this rule does not match, the next rule is validated. This process is
performed until a rule is found in which the values of the payment order or payment item characteristics match
the value range defined in a specific rule.

Each rule has a pointer to a business object such as a route, a clearing agreement, or a charge condition in
the clearing area for the executed payment transaction. In this way, you can use rule sets to implement the
business rules that the financial institution has defined. As soon as the system has found the first matching
rule (lowest sequence number), the search is canceled and the result (business object) is assigned to the
payment order or item. Thus, you place detailed rules as first rules and general rules toward the end of the rule
set.

Payment Engine (FS-PE)

190 PUBLIC Master Data
Generally, you can use all attributes of the Payment Engine metaformat, that is, payment order and payment
item characteristics, to define the rule sets. In addition, you can use other characteristics to restrict the validity
time of a rule, for example, date or time of day.

Furthermore, you can individually activate and deactivate each rule in a rule set. The system checks only
activated rules. You can reactivate a deactivated rule at any time. For more information, see Rule Set [page
188].

Operators and Checks for Rule Determination

On the basis of payment order and payment item information, the system can determine business objects,
such as routes, clearing agreements, or charge conditions for a payment item.

The following operators and checks are available to determine a rule and its corresponding business object:

• Equality operators
Compares a predefined value of an attribute in a rule with the current value of a given payment item or
payment order.
• Interval check
Checks whether the given attribute value lies within the interval that can be defined with the help of “from”
and “to” values.
• Pattern matching
Is possible using wildcard characters (“+” for any single character, “*” for any string). You can mix fixed
text components of the rule maintenance with wildcards. Pattern matching is not possible for numerical
information, for example, the transaction amount.
• Comparison operators
Can be determined during rule maintenance. You can use the following comparison operators:
• = Equal to
• ≥ Greater than or equal to
• ≤ Less than or equal to
• > Greater than
• < Less than
• ≠ Not equal to
• List membership check
Is performed in a rule set when several comparison values can be used within an individual rule.

To speed up the rule-determination process, some index logic is built into the rule set configuration. The index
logic creates indexes for rules when rules are saved so that similar rules (sharing the same characteristics) are
grouped into one index entry. If any rule in an index entry does not match the input parameters, the system
searches in the next index entry, thus eliminating rules from the search that do not match.

Example

Rule Set

Payment Engine (FS-PE)

Master Data PUBLIC 191
A rule set for routes contains the following rules:

Sequence Transaction Payment Or- BIC Currency Amount Further At- Route
Code der Priority tributes

1 Normal XXDEFF* EUR > 100.000 None ROUTE_1

2 5001 Normal ++++DE* EUR 100.000 – None ROUTE_2

1.000.000

3 5+++ Urgent YY* USD None ROUTE_3

4 5000 – 6000 ++++US* USD, CAD None ROUTE_4

Explanation

The system checks these rules against the payment order and payment item characteristics and determines
the route:

1. If the payment order and payment item characteristics equal this rule, route 1 is determined:
Every transaction code and payment order priority = Normal for any bank identifier code “XX Bank in
Frankfurt” in the currency EUR with an amount > 100,000.
2. If the payment order and payment item characteristics equal this rule, route 2 is determined:
Every transaction code 5001 and payment order priority = Normal for any bank identifier code in Germany
in the currency EUR with an amount between 100,000 and 1,000,000.
3. If the payment order and payment item characteristics equal this rule, route 3 is determined:
Every transaction code starting with 5 and payment order priority = Urgent for any bank identifier code of
the YY Bank in the U.S. in the currency USD with any amount.
4. If the payment order and payment item characteristics equal this rule, route 4 is determined:
Every transaction code in the interval 5000 – 6000 with any payment order priority for any bank identifier
code in the U.S. in the currency USD or CAD with any amount.

13.2 Charges

SAP Payment Engine supports the calculation of charges and fees (bank-to-bank fees and customer fees)
required in the context of cross-border payment processing. It uses the standard SAP component Financial
Conditions (CA-FIM-FCO) where you can store and manage the financial conditions for payment transaction
charges.

The Financial Conditions component provides the following functions:

• Management of standard and individual financial conditions

• Management of charge amounts and percentage values for predefined attributes
• Group individual conditions by condition groups based on a special condition group type

SAP Payment Engine uses rule sets within service level agreements (SLA) to calculate and process charges.
For charge calculation, condition groups can be assigned as results to SLA rules (Ruleset: Charge Processing).
Condition groups are part of the SAP cross-application component Financial Conditions (CA-FIM-FCO).

Payment Engine (FS-PE)

192 PUBLIC Master Data
Condition groups and standard conditions can be maintained via transaction Edit Condition Group - F9COGR2.
Individual conditions can be maintained by navigating directly from the SLA rule result to the condition group.

For more information on conditions, see the documentation about the SAP cross-application component
Financial Conditions (CA-FIM-FCO). On https://help.sap.com, search for Financial Conditions (CA-FIM-
FCO).

Additional charge settlement options can be defined via SLA charge rulesets such as determination of charge
accounts, charge bearer determination and charge settlement configuration.

Switching on Charge Calculation for Items

For performance reasons, charge calculation for payment items is switched off by default in the standard
system.

To switch it on, carry out the following steps:

1. In Customizing for Payment Engine, go to Payment Item Transaction Types and Transaction Type
Groups Define Transaction Types .
2. Select the relevant Clearing Area and Transaction Type.
3. Activate the ChrgCalc (Charge Calculation) switch.
4. Save your changes.

Charge Rule Sets

You define how charges are calculated and processed by setting up separate charge rule sets for the charge
processes used by your bank. The rule sets are defined at SLA level. For each SLA you specify which rules apply
to which charge process. You can configure different rules for different payment order, payment item, or charge
process criteria. The process rules are executed in the sequence specified by the sequence number.

You create separate rule sets for the following:

• Charge Processing
In this rule set, you specify the following:
• The condition group type and condition group used to calculate the charge amount.
• Which local application ID is used to post the charge. The local application ID can point to a specific
class used for processing, or to a separate system, for example, an external Account Management
system.

 Note

For more information on the application IDs used for charges, see below.

• Charge Bearer
In this rule set, you specify whether the order recipient (Choose Charge Bearer – Receiver), or the ordering
party (Do not choose Charge Bearer – Receiver) incurs the charges.

Payment Engine (FS-PE)

Master Data PUBLIC 193
  Note

If the system cannot determine a valid charge bearer rule, it first checks whether a bearer is specified
in the condition type. If nothing is found, item details are considered (see table below). If no charge
bearer could be determined at this point, the charges are shared between the sender and the recipient
(SWIFT: SHA).

If you have not defined any rule sets that determine the charge bearer, Payment Engine supports the
following scenarios:

Payment of Charges - Scenarios Supported by SAP Payment Engine

SWIFT ISO20022 Description

BEN CRED The beneficiary pays all charges, that is, the charges of the bank and the correspondent
bank. These charges are deducted from the amount transferred. Therefore, the beneficiary
does not receive the full amount.

SHA SHAR The sender pays the bank charges for international payment transfers and the beneficiary
pays the correspondent bank charges.

OUR DEBT The sender pays all charges incurred for payment transfer, that is, the charges of the bank
and the correspondent bank. The beneficiary receives the full amount.

• Charge Account
In this rule set, you specify the details of internal accounts to be used for posting charges. If none are
specified, the item account details of the charge bearer are used as charge account.

How are Charge Amounts Calculated?

SAP Payment Engine uses the standard SAP component Financial Conditions (CA-FIM-FCO) to store and
manage the financial conditions for charges. The condition group is used to calculate the correct charge
amounts. A condition group consists of one or more conditions.

At condition type level you can assign a charge bearer and a charge process. You can do this in Customizing
under Payment Engine Basic Settings Charges Assign Condition Types .

You can define the conditions to be used for charge calculation in two ways:

• By specifying the condition group (with conditions) in the relevant charge rule set (Charge Processing) in
the service level agreement (SLA).
• By assigning a condition type directly to a product in Customizing under Payment Engine Basic
Settings Charges Assign Condition Types to Products .

 Note

If conditions can be derived in both ways, only the conditions assigned to the product are used.

You can use further differentiation categories to help determine the correct conditions.

You can assign up to five differentiation categories to a condition type.

Payment Engine (FS-PE)

194 PUBLIC Master Data
By assigning specific values to these categories, you restrict the use of a condition to objects that meet this
selection criteria.

Example

You assign the differentiation category Account Type to a condition type. You create a condition (Condition
A) of this condition type in the condition group Example Condition Group.

You assign the value LORO to the Account Type in this condition.

The condition group Example Condition Group is specified in the charge rule set for charge process
Transaction Charges (002):

• You process a payment item with Account Type = LORO.

Condition A is used for charge calculation, because the differentiation criterion Account Type matches.
• You process a payment item with Account Type = NOSTRO.
Condition A is not used for charge calculation, because the differentiation criterion Account Type does
not match.

If this group is specified in a charge rule for calculating charges, it is only used for items where

What are the Standard Charge Processes?

Payment Engine offers the following standard charge processes, which you can configure to reflect the steps
that need to be carried out in that process.

Charge Processes supported by SAP Payment Engine

ID Charge Process Used For

001 Payment Order Submission Can be used if you submit a payment

in SAP Payment Engine and you want to
deduct charges for payment submission
using a specific channel;

002 Transaction Processing Can be used if you process a payment in

SAP Payment Engine;

003 Routing Charge Can be used if you send a payment to a

different bank or forward a payment via
an external file and need to increase the
settlement amount for charges that are
to be deducted by other financial institu-
tions;

Payment Engine (FS-PE)

Master Data PUBLIC 195
ID Charge Process Used For

004 Posting Charge Determines charges when posting items

for internal recipients (for example, if the
beneficiary pays the charges BEN);

005 Externally Supplied Charge If an externally supplied charge was pro-

vided in an imported file, this charge
process checks the charge amount:

• If it is sufficient, it posts the charge;

• If it is insufficient, a charge request
can be triggered (process ID 081);

006 Charges for Clearing This is a technical charge process that is

triggered by the system. It is used when
the item is not posted itself, but posting
occurs via a clearing item. In this case,
the sum of charges is transferred to the
clearing item using this process;

010 Charge for Recall Submission If you submit a recall (via file for exam-
ple), you can use this process to deduct a
charge;

011 Charge for Recall Processing Determines charges during recall proc-
essing;

020 Charge for Status Notification If a status notification is created, you can
use this process to deduct a charge;

030 Charge for Account Substitution If an account substitution takes place,

you can uses this process to deduct a
charge;

040 Charge for Correspondence If a correspondence is created, you can

uses this process to deduct a charge;

070 Charge for Postprocessing If the payment is sent into postprocess-

ing and a user has to manually correct
the transaction details, you can use this
process to deduct a charge;

Payment Engine (FS-PE)

196 PUBLIC Master Data
ID Charge Process Used For

080 Charge Balancing Process This is a technical charge process that

is triggered by the system in order to bal-
ance the charge amount.

Examples:

• The charge amount is to be ne-

glected due to threshold customiz-
ing;
• The charge amount is higher than
the transaction amount;

081 Request Charge This is a technical charge process that

is triggered by the system, if externally
supplied charges are insufficient (charge
process 005), and a charge request has
been configured;

090 Free Charge This process allows you to freely define

charges via the user interface;

Settlement of Charges

Different types of charge settlement can be employed by specifying different Local Application IDs. In detail, the
following Local Application Systems are relevant for charge settlement:

• CHRG_PI: The calculated charges are settled directly with the payment item of the responsible charge
bearer;
• CHRG_PO: A separate payment order is created for the charge;
• CHRG_REQ: Request charge (for example, due to insufficient charge credit posting from external bank).
Posting is also triggered via a separate payment order, but with a different type of mapping;

Local Application Management Systems can be assigned to Local Application Area IDs (referred to as Local
Application IDs in the following).

You can specify which Local Application ID is used in the corresponding charge processing rule set.

For each application ID, you can also define an alternative application ID in Customizing. If an application ID
cannot be used, the system uses the alternative ID instead.

If a rule set does not contain an application ID, the system uses the default application ID defined for the
process application category defined in Customizing.

You maintain both the alternative application ID and the default application ID in Customizing under Payment
Engine Basic Settings Local Application Management Systems Define Local Application Management
Areas .

The following table shows which applications systems can be used in which standard charge processes.

Payment Engine (FS-PE)

Master Data PUBLIC 197
Application System Used For Can be Used in Charge Process ID

CHRG_PI Charge posting via payment item All processes, except:

• 081 (Request Charge)

• If a different charge account has to
be used (customizing in SLA);
In this case, you can only use
CHRG_PO;

CHRG_PO Charge posting via payment order All processes except 81;

CHRG_REQ Interbank charge request 081 (to request charge from the send-
ing bank);

Charge Scenario Examples

The following are scenario examples of how charge processing is performed. They indicate the relevant
customizing steps that might be required:

• A customer has submitted a payment. A charge of 10 Euros is calculated via transaction charges (charge
process Transaction Processing (002)). The initiating customer is determined as charge bearer (OUR). A
customer defined application ID with application system CHRG_PI is used to post the 10 Euro charge to the
ordering party
In addition, a routing charge of 5 Euros (charge process Externally Supplied Charge (005)) is calculated for
subsequent financial institutions in the transaction chain when forwarding the recipient item. This charge
sum is transferred to the clearing item (charge process Charges for Clearing (006)), thus crediting 5 Euros
to the clearing account (for example, this amount will be added to field 71G in an outbound SWIFT file).
• You receive an interbank credit transfer for an internal recipient for which the charges are to be paid by
the recipient (BEN). When posting the recipient item, a charge of 5 Euros is calculated via charge process
Posting Charge (004). Charge posting can occur either directly with the item or as a separate charge
posting order.

Related Information

Editing Charge Conditions [page 199]

Differentiation Categories [page 200]
Basic Cross-Border STP [page 101]

Payment Engine (FS-PE)

198 PUBLIC Master Data
13.2.1 Editing Charge Conditions

Context

You edit conditions based on the Payment Transaction Charges condition group type. The condition group is
assigned to the service level agreement and clearing agreement. SAP Payment Engine uses charge processing
rule sets created in the service level agreement to calculate and process charges.

 Note

The following procedures describe how to edit charge conditions if the standard SAP component Financial
Conditions (CA-FIM-FCO) is used to store and manage the financial conditions for payment transaction
charges. For information about Financial Conditions (CA-FIM-FCO), on https://help.sap.com, search
for Financial Conditions (CA-FIM-FCO).

Carry out the following steps to define rules for calculating and processing charges:

Procedure

1. To select the SLA for which you want to set up charge rule sets, on the SAP Easy Access screen choose
Payment Engine Master Data Service Level Agreements Manage Service Level Agreements
(transaction /PE1/SLA). Switch to edit mode.
2. Select the SLA General tab and activate Charges Functions.

A Charges tab appears.

3. Select the Charges tab.
4. For Charge Processing choose Set of Rules.

A Charge Calculation and Processing section opens:

a. Click on the Create Rule Set icon to enter a new rule. A Rule Maintenance appears.
b. If you want the rule to apply only to payment orders/payment items with particular attributes, or if you
want it to apply only to specific charge (sub-)processes, specify these restrictions in the left panel of
the Rule Maintenance popup.
c. Enter a condition group for the charge calculation, and a local application ID for charge processing.

 Note

If you enter more than one rule (for example, to define different processes depending on particular
payment order attributes, they will be processed in the sequence shown in the Charge Calculation
and Processing section.

5. For Charge Bearer choose Set of Rules.

A Charge Bearer section opens:

a. Click on the Create Rule Set icon to enter a new rule. A Rule Maintenance appears.
b. If you want the rule to apply only to payment orders /payment items with particular attributes, or if you
want it to apply only to specific charge (sub-)processes, specify these restrictions in the left panel of
the Rule Maintenance popup.

Payment Engine (FS-PE)

Master Data PUBLIC 199
 c. If you want to assign the charges to the receiver, choose Charge Bearer – Receiver). If not, leave the
field blank and choose OK.
6. For Charge Settlement choose Set of Rules.

A Charge Settlement section opens:

a. Click on the Create Rule Set icon to enter a new rule. A Rule Maintenance appears.
b. If you want the rule to apply only to payment orders /payment items with particular attributes, or if you
want it to apply only to specific charge (sub-)processes, specify these restrictions in the left panel of
the Rule Maintenance popup.
c. Charge Account Details: Add the criteria you want to use to determine the correct internal accounts to
be used for posting charges.

Results

You have defined charge conditions and can now assign the charges to the corresponding service level
agreements and clearing agreements.

Related Information

Charges [page 192]

Differentiation Categories [page 200]
Service Level Agreement [page 256]

13.2.2 Differentiation Categories

Use

In SAP Payment Engine you can use differentiation categories to help determine the correct conditions to use
for calculating charges.

SAP Payment Engine provides the following differentiation categories:

Differentiation Categories available in SAP Payment Engine

Description

D01 BIC

D02 Charge Type

D03 Transaction Type

Payment Engine (FS-PE)

200 PUBLIC Master Data
 Description

D04 Payment Order Type

D05 STP Capability

D07 Recall Type

D08 Return Reason

D09 Recall Group

D10 Number Recipient Items

D12 Medium

D13 Channel

D14 Format

D20 Status Notification Template ID

D21 Status Notification Type ID

D30 Product

D31 Product Group

D32 Instruction Code

D33 Currency Group

D34 Country Group (Recipient)

D35 Country (Recipient)

D36 Account Type

Activities

You can manage differentiation categories in Customizing for Payment Engine under Basic Settings
Charges Define Differentiation Categories .

To assign condition categories to them in Customizing, go to Payment Engine Basic Settings Charges
Assign Condition Categories to Differentiation Categories .

Payment Engine (FS-PE)

Master Data PUBLIC 201
More Information

Charges [page 192]

Editing Charge Conditions [page 199]

13.3 Bank File Clearing

Definition

A set of bank master data used to determine the clearing account of ordering party items for incoming
payments orders.

Use

You manage bank file clearing data to support the posting of ordering party items assigned to incoming
payment orders for interbank payments. During the enrichment and validation process, the system enriches
the account data for the ordering party item of an interbank payment.

 Note

You must specify that the enrichment and validation check for bank file clearing is specified in the found
check set. For more information, see Enrichment and Validation [page 311].

The system uses the data provided in the incoming order for the ordering party item, for example, the payment
order type, the currency of the transaction, and/or the bank identifier code (BIC), to enrich the bank file
clearing account data.

 Example

An incoming payment order contains only the bank identifier code (BIC) of the external sender of the
payment. The system checks the payment order and enriches the account data for the ordering party
item of the payment order. The correct bank file clearing data is found based on the data provided in the
incoming payment order, for example, the payment order type, the currency, and the BIC.

Structure

Header data

• Clearing area

Information about the incoming payment order

Payment Engine (FS-PE)

202 PUBLIC Master Data
• Payment order type
• Currency amount total of the ordering party item
• Sender bank country (external)
• Sender bank key (external)
• Bank identifier code (BIC) of external sender
• Bank country of recipient
• Bank key of recipient
• Bank identifier code (BIC) of recipient
• Name of the recipient of the payment order

Information for clearing and settlement

• Settlement method
• Clearing system ID

Information about the clearing account

• Bank identifier code (BIC)

• Bank key
• Bank country
• Account number
• Account currency
• IBAN
• Account holder

Indicator for separate provision of cover

 Note

You choose this indicator when neither financial institution has a clearing account with the other. Although
the financial institutions exchange information about the payment directly, the settlement amount is
reached with the help of a third party. In the bank file clearing data, the information required about this third
party is the information about the clearing partner account.

Information about handling of clearing orders

• Credit transaction type for internal clearing order

• Debit transaction type for internal clearing order
• Order type for internal clearing
• Payment order priority

Information about the clearing partner account

• Account number
• Account currency
• Bank country
• Bank key
• IBAN
• Bank identifier code (BIC)
• Account holder

Payment Engine (FS-PE)

Master Data PUBLIC 203
Alternative

 Note

Another way to determine the clearing account for an ordering party item is via the business partners of the
sender. For more information, see Payment Order Checks [page 316].

More Information

Manage Bank File Clearing Accounts [page 204]

13.3.1 Manage Bank File Clearing Accounts

Use

You use this function to manage bank master data that Payment Engine uses to determine the bank file clearing
account of incoming payments orders during the enrichment and validation process. This clearing account is
used to post the ordering party item for interbank payments.

Prerequisites

• You have defined clearing areas in Customizing for Payment Engine by choosing Basic Settings
Organization Define Clearing Area .
• You have defined payment order types in Customizing for Payment Engine by choosing Payment Order
Define Payment Order Types .
• You have defined clearing system IDs in Customizing for Payment Engine by choosing File Handler
Basic Settings Maintain Clearing System Identifications .
• For information about how to implement enrichment and validation checking for bank file clearing, see
Enrichment and Validation Checking [page 315] and Payment Order Checks [page 316].

Activities

To manage bank file clearing accounts, on the SAP Easy Access screen, choose Payment Engine Master
Data Bank File Clearing Manage Bank File Clearing Accounts (transaction /PE1/MN_BFC_N).

Payment Engine (FS-PE)

204 PUBLIC Master Data
More Information

Bank File Clearing [page 202]

13.4 Routing Control (FS-PE-RP)

Use

This component determines the relevant business objects for the further processing of payment items. These
business objects contain information that is necessary to transfer money from one financial institution to
another. During route processing, the system analyzes each payment item to evaluate how it should be
processed and links various business objects to each payment item by using flexible rule sets.

First, the system analyzes whether a payment is internal (the beneficiary is a customer of the financial
institution processing the payment) or external (the beneficiary is not a customer of the financial institution
processing the payment).

The system analyzes internal payments to evaluate whether there is a special agreement with the beneficiary,
such as the instruction to collect certain payments instead of posting every single payment item to an account.
If a financial institution uses different account management applications for different lines of business, the
system locates the relevant account management application.

The system analyzes external payments to evaluate the preferred outgoing channel or payment method.
These channels or methods can be used to forward payments to local or international clearing systems or the
appropriate financial institutions.

In Routing Control, the following business objects are relevant:

• Route
For more information, see Route [page 207].
• Clearing agreement
For more information, see Clearing Agreement [page 219].
• Customer agreement
For more information, see Customer Agreement [page 231].
• Valute date agreement
For more information, see Value Date Agreement [page 244].

Integration

Routing Control receives payment items that have been enriched and checked in the enrichment and validation
process of Payment Processing. It delivers these payment items to Clearing Processing with a reference to
a specific route, customer agreement (if present), clearing agreement, and value date agreement. These
references are logical paths that provide details about how the system processes the payment items in the
Clearing Processing component.

Payment Engine (FS-PE)

Master Data PUBLIC 205
For more information about the connected process and components, see:

• Payment Processing (FS-PE-POP) [page 309]

• Enrichment and Validation [page 311]
• Clearing Processing (FS-PE-CP) [page 337]

Routing Control is also connected to the Exception Control component to handle errors occurring during route
processing. For more information, see Exception Control (FS-PE-EH) [page 265].

Rule Sets
A rule set and its rules are related to the business objects in Routing Control in the following ways:

• A rule refers to exactly one route, one clearing agreement, or one value date agreement. The same route,
clearing agreement, or value date agreement can occur in several rules.
• A route has exactly one general dependant rule set for the determination of a clearing agreement.
Moreover, each combination of route and customer agreement has a maximum of one dependant rule
set for the determination of a customer clearing agreement.
• A certain number of clearing agreements belong to one route. One clearing agreement belongs to exactly
one route.
• A customer agreement can contain exactly one rule set for exactly one route with one or more rules. A
number of customer clearing agreements belong to a customer agreement.
• A customer agreement and all associated customer clearing agreements always relate to one route only.
• A route can relate to several customer agreements.
• A value date agreement is assigned to exactly one value date agreement rule set.
• Each route refers to exactly one value date agreement rule set. Each clearing agreement refers to one value
date agreement rule set or none at all. A value date agreement rule set can be assigned to any number of
clearing agreements or routes.

Features

You can manage routes, clearing agreements, customer agreements, and value date agreements and their rule
sets as follows:

• To manage routes, clearing agreements, customer agreements, and their associated rule sets:
SAP Easy Access Payment Engine Master Data Routing Control Manage Routes and Clearing
Agreements (transaction /PE1/RN)
• To manage value date agreements and their associated rule sets:
SAP Easy Access Payment Engine Master Data Routing Control Manage Set of Rules for Value
Date (transaction /PE1/VA)

You can use a release workflow to supervise the creation, change, and deletion of business objects and their
rule sets in Routing Control. For more information, see Release Workflow [page 419].

Payment Engine (FS-PE)

206 PUBLIC Master Data
13.4.1 Route

Definition

An object that indicates whether a payment item is to be posted internally or externally:

• Internally
The beneficiary is a customer of the financial institution processing the payment. A route serves internally
to determine to which account management area payment items have to be posted.
• Externally
The beneficiary is not a customer of the financial institution processing the payment. A route serves
externally to determine the clearing institute for outgoing payment orders.

A route is determined for each payment item and additionally groups clearing agreements.

Use

Internal routes define which account management area and therefore which account management system
is relevant for a certain internal beneficiary of a payment item or for a certain ordering party of a payment
item. If a financial institution has two or more internal account management systems, the correct account
management system for a particular situation is found. For internal payments items, the system first searches
for a customer clearing agreement. If no customer clearing agreement is found, the system searches for a
standard internal clearing agreement. Both agreements are directly linked to an internal route.

External routes roughly classify the direction of external payments. External clearing agreements are linked to
external routes.

You can set a lock for outgoing processing on the route level, meaning that the processing of outgoing
payments for all clearing agreements assigned to the route is temporarily blocked. This lock could be used, for
example, to temporarily stop all forwarding of U.S. dollar payments. As a result, the system does not generate
any outgoing payment orders for any channel assigned to this route until you cancel the lock.

The system analyzes the route rule set in one clearing area and thereby considers only active routes. If a new
route is in processing or for release, the old route is still active. As soon as the new route is released, the old
route is replaced by the new route. For more information about the release workflow, see Release Workflow
[page 419].

If the system cannot determine any valid route because no appropriate rule can be found, Routing Control
raises an exception and hands the error situation to Exception Control. This component defines an adequate
response for the exception. For more information, see Exception Control (FS-PE-EH) [page 265]. To avoid this
kind of error, you can define a default route by creating a rule without conditions. You attach this rule as the last
rule in the rule set.

You can manage routes and their rule sets as follows:

On the SAP Easy Access screen, choose Payment Engine Master Data Routing Control Manage Routes
and Clearing Agreements (transaction /PE1/RN). For more information, see Managing Route Rule Sets [page
210] and Managing Route Rules [page 212].

Payment Engine (FS-PE)

Master Data PUBLIC 207
Structure

Route Screen

The route screen is organized in the following screen areas:

• Search area
You can enter a text to search for routes currently loaded in the navigation tree. When you run a search, a
new node with the result is created in the tree.
• Navigation tree
Displays existing routes, clearing agreements, and customer agreements in a hierarchical structure.
• Business object
Displays details about the selected route, clearing agreement, or customer agreement organized on tab
pages.
• Rules
Displays the rules in a rule set associated with the selected route or clearing agreement.

Route Screen

Route Details

On the route screen, you can find the following business object information. This information can differ for
internal and external routes. If any of the sections described below only applies to one of these types, the
section is indicated as “(internal only)” or “(external only)”:

Header Data

Route information

Contains the route ID, its description, and the release status of the route.

Basic Data

• Route status
A route can have the following route statuses:
• Active

Payment Engine (FS-PE)

208 PUBLIC Master Data
 • Inactive
• Flagged for deletion
• Internal/external indicator
Specifies whether the entry refers to external or internal postings on the recipient side. External postings
are postings to external financial institutions, which means that a new payment order is generated and sent
to Output Manager. Internal postings are postings to accounts managed by the same financial institution
processing the payment.
• Lock outgoing payment orders
Indicates whether a route is locked. Payment items that are within this locked route are not released
through this route and therefore remain in a queue until they are manually released from the queue.
• Bank at Route group box (external only)
Provides details about the external bank, such as bank country, bank key, and account number.
• Value Dating group box
Indicates the calendar and the rule set for value date agreement that is used to determine the value date
for payment items processed through this route. For more information, see Value Date Agreement [page
244].

Integration

Once the system has determined a route, a search for clearing agreements grouped under the determined
route is performed. If the system cannot determine any clearing agreement, the route is not used and the
system has to determine a new one.

With regard to rule sets, the following applies:

• A route rule set consists of one or more rules.

• One rule refers to exactly one route. The same route can occur in several rules.

For more information about rule sets, see Rule Set [page 188].

Routes are integrated within the Routing Control component. After routing, the payment items are delivered to
the Clearing Processing component with reference to a route. The information in this route together with the
information in the referenced clearing agreement determine how the system processes the item.

For more information, see Routing Control (FS-PE-RP) [page 205] and Clearing Processing (FS-PE-CP) [page
337].

More Information

Clearing Agreement [page 219]

Payment Engine (FS-PE)

Master Data PUBLIC 209
13.4.1.1 Managing Route Rule Sets

Use

You can manage route rule sets as follows:

• Create a route rule set

You can create a route rule set by creating the first rule for a rule set in a clearing area. The system then
automatically creates a route rule set.
• Change a route rule set
You can change a route rule set by adding, changing, or deleting rules in the rule set. In addition, you can
activate or deactivate rules in the rule set.
• Delete a route rule set
You can delete a route rule set by deleting all rules in the rule set.
• Display a route rule set
You can display a route rule set by displaying a route associated with this rule set.

Prerequisites

To create, change, and delete a route and its rule set:

• You have defined the release workflow in Customizing for Payment Engine under Routing Control
Release Route and Rule Set .
• You have the necessary rights to change and create a route and its rule set for the selected clearing area.

To display a route and its rule set:

You have display rights for the selected clearing area.

Procedure

On the SAP Easy Access screen, choose Payment Engine Master Data Routing Control Manage Routes
and Clearing Agreements (transaction /PE1/RN), enter a clearing area, and continue.

 Note

You can show or hide the search area and navigation tree by choosing the Switch Overview Tree On/Off
pushbutton.

Creating Route Rule Sets

Creating Route

1. Choose the Route pushbutton, enter an ID for the new route, and continue.
You can also copy an existing route on which you base your new route.

Payment Engine (FS-PE)

210 PUBLIC Master Data
2. Enter data as required.
3. Save the object and trigger the release process by choosing the Release pushbutton.

 Note

You can process only objects with Released status.

Creating Route Rule

Create a route rule.

For more information, see Managing Route Rules [page 212].

When you save the rule, the system automatically creates the rule set.

Changing Route Rule Sets

1. From the navigation tree, double-click the route associated with the rule set that you want to change.
2. In change mode, you can change the route in the business object screen area and the route rule set in the
rules screen area.
For more information about the screen areas on the route screen, see Route [page 207] under Structure.

 Note

You can show or hide the rule set by choosing the Set of Rules pushbutton.

3. Make the required changes.

You can create, change, and delete rules in the rule set. Furthermore, you can activate or deactivate rules in
the rule set.
For more information, see Managing Route Rules.
4. Save the object and trigger the release process by choosing the Release pushbutton.

 Note

You can process only objects with Released status. If the object is not released, the old rule applies.

Deleting Route Rule Sets

1. From the navigation tree, double-click a route associated with the rule set that you want to delete.

 Note

You can show or hide the rule set by choosing the Set of Rules pushbutton.

2. In change mode, choose the Delete Rule Set pushbutton to set all rules in the rule set to Flagged for
Deletion.

 Note

When you delete a rule set, the system also deletes all rules associated with the rule set.

3. Save the object and trigger the release process by choosing the Release pushbutton.

 Note

The object is actually deleted when it reaches the Released status.

Displaying Route Rule Sets

Payment Engine (FS-PE)

Master Data PUBLIC 211
From the navigation tree, double-click the route of which you want to display the rule set.

The route details are displayed in the business object screen area. The route rule set is displayed in the rules
screen area.

13.4.1.2 Managing Route Rules

Use

You can manage route rules as follows:

• Create a route rule

You can create a rule that is used during routing process to determine the route.
• Change a route rule
You can change the behavior in the route determination by changing characteristics in the rule. You can
only change route rules by changing a route.
• Delete a route rule
You can delete a route rule by changing a route.
• Display a route rule
You can display a rule for a route to see the characteristics of the rule that define its behavior.

Prerequisites

To create, change, and delete a route and its rules:

• You have defined the release workflow in Customizing for Payment Engine under Routing Control
Release Route and Rule Set .
• You have the necessary rights to change and create a route and its rules for the selected clearing area.

To display a route and its rules:

You have display rights for the selected clearing area.

Procedure

On the SAP Easy Access screen, choose Payment Engine Master Data Routing Control Manage Routes
and Clearing Agreements (transaction /PE1/RN), enter a clearing area, and continue.

 Note

You can show or hide the search area and navigation tree by choosing the Switch Overview Tree On/Off
pushbutton.

Creating Route Rules

Payment Engine (FS-PE)

212 PUBLIC Master Data
1. From the navigation tree, double-click a route associated with the route rule set where you want to add a
rule.
2. In change mode, you can change the route in the business object screen area and the route rules in the
rules screen area.
For more information about the screen areas on the route screen, see Route [page 207] under Structure.

 Note

You can show or hide the rules by choosing the Set of Rules pushbutton.

3. Do one of the following:

• Create a new rule by choosing in the rules screen area.

The dynamic selection screen (rule maintenance) appears where you can choose the characteristics
for the rule.

• Copy an existing rule by choosing in the rules screen area.

4. Enter data as required.
5. Save the object and trigger the release process by choosing the Release pushbutton.

 Note

You can process only objects with Released status.

Changing Route Rules

1. From the navigation tree, double-click a route associated with the route rule set where you want to change
a rule.
2. In change mode, you can change the route in the business object screen area and the route rules in the
rules screen area.
For more information about the screen areas on the route screen, see Route under Structure.

 Note

You can show or hide the rules by choosing the Set of Rules pushbutton.

3. In the rules screen area, choose the rule that you want to change and choose .
The dynamic selection screen (rule maintenance) appears where you can choose the characteristics for
the rule.
4. Make the required changes.
5. Furthermore, you can do one of the following:

• Activate a rule in the rule set by choosing .

• Deactivate a rule in the rule set by choosing .

6. Save the object and trigger the release process by choosing the Release pushbutton.

 Note

You can process only objects with Released status. If the object is not released, the old rule applies.

Deleting Route Rules

1. From the navigation tree, double-click a route associated with the route rule set that contains the rule to be
deleted.

Payment Engine (FS-PE)

Master Data PUBLIC 213
2. In change mode, you can change the route in the business object screen area and the route rules in the
rules screen area.
For more information about the screen areas on the route screen, see Route under Structure.

 Note

You can show or hide the rules by choosing the Set of Rules pushbutton.

3. In the rules screen area, choose the rule that you want to delete and choose .
The rule is selected for deletion.
4. Save the object and trigger the release process by choosing the Release pushbutton.

 Note

You can delete only objects with Released status.

Displaying Route Rules

1. From the navigation tree, double-click the route of which you want to display a rule.
The route details are displayed in the business object screen area. The route rules are displayed in the rules
screen area.
For more information about the screen areas on the route screen, see Route under Structure.

 Note

You can show or hide the rules by choosing the Set of Rules pushbutton.

2. Choose the rule that you want to display and choose .

The dynamic selection screen (rule maintenance) appears where you can check the details of the rule.

13.4.1.3 Release Object ROUTE (Route)

Definition

A release object in Payment Engine used by the system to identify whether the editing of a route or route rule
set by an author or a processor is subject to release.

If the editing of the route or its rule set is subject to release, the system generates a release object ROUTE
(route) as a work item that can be processed further by a supervisor or user responsible for release in the
Business Workplace.

Use

Customizing

In Customizing, you can define how many release steps the object must pass (for example, for dual or treble
control) and the conditions when the release workflow is carried out (for example, always, conditional by using
release attributes).

Payment Engine (FS-PE)

214 PUBLIC Master Data
You make the settings for release object ROUTE in Customizing for Payment Engine under Routing Control
Release Route and Rule Set in the following Customizing activities:

• Assign Release Procedure to Release Object

• Assign Standard Role to Release Steps
• Assign Workflow and Sub-Workflow to Release Procedure

Channel

Dialog

Individual processing: transaction Manage Routes and Clearing Agreements (/PE1/RN)

The system checks whether the dialog processing of the route or its rule set is subject to release, and
generates a work item for every release-relevant route or rule set. If a route or its rule set is no longer subject to
release after processing, the system deletes the associated work item.

Business Application Programming Interface (BAPI)

Like during dialog processing, the system checks whether editing a route or its rule set by using BAPIs is
subject to release and generates a work item for every release-relevant editing. If a route or its rule set is no
longer subject to release after editing, the system deletes the associated work item.

Structure

You can edit release object ROUTE as a work item in the Business Workplace. These methods can affect the
status of the route. For more information, see Status and Release Status of Master Data Objects [page 216].

• Display
Choosing this pushbutton brings you to the dialog transaction Manage Routes and Clearing Agreements.
• Change
Choosing this pushbutton brings you to the dialog transaction Manage Routes and Clearing Agreements.
The system closes the old release workflow and triggers a new release process with the changed data. The
status of the new route release object is initially For Release. This method in the Business Workplace can
change the status and release status of the route as follows:
The system checks the changed item and generates a new work item if applicable and deletes the existing
work item.
• Display change documents
Choosing this pushbutton opens the dialog transaction Manage Routes and Clearing Agreements with
dialog box Display Change Documents of the route.
• Release
This method in the Business Workplace can change the status and release status of the route as follows:
Editing the route:

Before Release After Release

Status of the Route Release Status Status of the Route Release Status

Inactive For Release Active Released

Payment Engine (FS-PE)

Master Data PUBLIC 215
• Reject
Choosing this pushbutton rejects the change of the route.
This method in the Business Workplace can change the status and release status of the route as follows:
Editing the route:

Before Release After Release

Status of the Route Release Status Status of the Route Release Status

Inactive For Release Active In Process

More Information

Route [page 207]

13.4.1.4 Status and Release Status of Master Data Objects

When you edit the following master data objects in SAP Payment Engine, the status and release status of the
object can change:

• Service level agreement and rule set for service level agreements
• Value date agreement and rule set for value date agreements
• Route and route rule set
• Clearing agreement and clearing agreement rule set
• Customer agreement and customer agreement rule set
• Exception control rule set

Payment Engine (FS-PE)

216 PUBLIC Master Data
The following graphic illustrates the possible statuses for all these objects:

Status and Release Status of a Master Data Object

 Note

To activate the creation or change of an object, always use the release pushbutton even if no release
workflow is set in Customizing for Payment Engine.

Related Information

Release Object SLA (Service Level Agreement) [page 261]

Release Object ROUTE (Route) [page 214]
Release Object CA (Clearing Agreement) [page 227]
Release Object CUSTAGR (Customer Agreement) [page 239]
Release Object CAGRASS (Assignment of General Customer Agreement) [page 241]

Payment Engine (FS-PE)

Master Data PUBLIC 217
Release Object EH (Exception Control Rule Set) [page 280]
Foreign Exchange (FX) [page 284]

13.4.1.5 Entering Master Data for Bulk Assignment of

Request Agents

Use

You can enter master data to enable the bulk assignment of request agents in payment order bulking.

Prerequisites

You have made the following settings in Customizing for Payment Engine (FS-PE):

• You have defined the required bulk types under File Handler Bulking Define Bulk Types .
• You have set up the required format, medium, and channel in the respective activities under File Handler
Basic Settings .

For more information, see the Customizing activity documentation.

Procedure

To enter the master data, proceed as follows:

1. From the SAP Easy Access menu, choose Master Data Routing Control Create Bulk Assignment of
Request Agents .
2. Choose New Entries.
3. Use the input help to enter the clearing area, request agent type and action, and the BIC.
4. In the Request Agent Bulk Assignment group box, use the input help to specify the required format,
medium, channel, and bulk type. The input help displays the data that you set up in Customizing.
5. To limit the bulk size, specify the maximum number items to be included.
6. Enter the required logical file.
7. Save your entries.

Result

You have entered the required data for the bulk assignment of request agents.

The report Request Agent Mass Processing can now create bulk content for report Bulk Files for Outgoing
Payments.

Payment Engine (FS-PE)

218 PUBLIC Master Data
More Information

• For more information about bulking files for outgoing payments, see the report documentation. From the
SAP Easy Access menu, choose Periodic Processing Processes Bulk Files for Outgoing Payments .
• For more information about bulking see Output Manager [page 295].
• For more information about request agent mass processing, see the report documentation. From the SAP
Easy Access menu, choose Periodic Processing Processes Request Agent Mass Processing .
• For more information about the request agent, see Request Agent [page 150].

13.4.2 Clearing Agreement

Definition

An object that specifies the conditions for the transfer of payment orders within or between financial
institutions (internal or external clearing agreement).

A clearing agreement includes the following parameters:

• Whether and how payment items are transferred individually or collectively

• How payment information is exchanged
• How the transaction value is procured

Each financial institution involved in the payment transaction has at least one clearing agreement with another
clearing institute.

Use

You can use clearing agreements to specify how the system processes internal and external payment items.

The system analyzes the clearing agreement rule set in one clearing area and considers only active clearing
agreements. If a new clearing agreement is in processing or for release, the old clearing agreement is still
active. As soon as the new clearing agreement is released, the old clearing agreement is replaced by the new
clearing agreement. For more information about the release workflow, see Release Workflow [page 419].

If the system cannot determine any valid clearing agreement because no appropriate rule can be found,
Routing Control raises an exception and hands the error situation to Exception Control. This component
defines an adequate response for the exception. For more information, see Exception Control (FS-PE-EH)
[page 265]. To avoid this kind of error, you can define a default clearing agreement by creating a rule without
conditions. You attach this rule as the last rule in the rule set.

If the system determines a clearing agreement to be used but you have set a lock to the according route, the
alternate route and clearing agreement are used.

Payment Engine (FS-PE)

Master Data PUBLIC 219
You can manage clearing agreements and their rule sets as follows:

On the SAP Easy Access screen, choose Payment Engine Master Data Routing Control Manage Routes
and Clearing Agreements (transaction /PE1/RN). For more information, see Managing Clearing Agreement
Rule Sets [page 222] and Managing Clearing Agreement Rules [page 224].

Structure

Clearing Agreement Screen

The clearing agreement screen is organized in the following screen areas:

• Search area
You can enter a text to search for clearing agreements currently loaded in the navigation tree. When you
run a search, a new node with the result is created in the tree.
• Navigation tree
Displays existing routes, clearing agreements, and customer agreements in a hierarchical structure.
• Business object
Displays details about the selected route, clearing agreement, or customer agreement organized on tab
pages.
• Rules
Displays the rules in a rule set associated with the selected route or clearing agreement.

Clearing Agreement Screen

Clearing Agreement Details

The clearing agreement screen contains the header data, basic data, administration data, and if the clearing
agreement is for external routes, the external clearing agreement data. This information may differ depending
on the clearing scenario (for example, direct clearing) and depending on how the payment items are processed
(for example, collect items).

Basic Data

Payment Engine (FS-PE)

220 PUBLIC Master Data
On this tab page, you can define the basic processing characteristics of your clearing agreement. Based on the
selection of the available attributes, additional data and tabs become available.

The screen is divided into different sections:

• Clearing Scenario
• Collection (opens an additional Collector Process tab)
• Clearing Time
• Individual Advice (only for internal clearing agreements; opens an additional Customer Advice
Information tab)
• Alternative Processing Options (opens an additional Customer Advice Information tab)
• Forwarding Options
• Forward Directly for outgoing order based processing; the order is directly forwarded to the File
Handler component
• Lock Outgoing Payments
• Value Dating
• Value Date Ruleset ID
• Alternative Clearing used, for example, for scenarios in which the clearing agreement is locked or in case of
other alternative scenarios in order to control further transaction processing

External Clearing Agreement

This tab page is displayed only for external clearing agreements.

 Note

• Account Symbol field

Since an account symbol can be used for several clearing agreements, it is easier to change
the account to be used by maintaining the account symbol instead of modifying several clearing
agreements. You can maintain account symbols in Customizing for Payment Engine under Clearing
Define and Maintain Account Symbols .
• Execution On checkbox
If you choose this option, the following fields are displayed:
• Base time
Specifies the date that the system uses to calculate the planned execution time of payment
transactions. If you choose the due date, the system uses the due date to calculate the planned
execution time of direct debit transactions and the planned closing time of the collector that
collects the corresponding payment items.
• Markup/Markdown
Specifies the number of days to be added to or subtracted from the base time to calculate the
planned execution time and planned closing date
• Bulk Type field
You specify the bulk type if you are bulking outgoing payment files and request agent outputs (for
example,CAMT files).

Internal Clearing Agreement

This group box is displayed only for internal clearing agreements if the Collection of Items is selected on the
Basic Data tab page, and the collection type is Collector on the Collector Process tab page.

Clearing Order

Payment Engine (FS-PE)

Master Data PUBLIC 221
This tab page is displayed only for external clearing agreements when the option for a clearing order is selected
on the External Clearing Agreement tab page. This option can be used to create a separate provision of cover
for your outgoing payments.

Collector Process.

This tab page is displayed only if you have selected the Collect Items checkbox on the Basic Data tab page.

For more information about the different collection types, see Queue [page 339] and Collector [page 346].

Integration

Clearing agreements are integrated in the Routing Control component. After routing, the system delivers
the payment items to the Clearing Processing component with the reference to a clearing agreement. The
information in this clearing agreement together with the information in the referenced route, customer
agreement (if present), and value date agreement determine how the system processes the payment items.

For more information, see Routing Control (FS-PE-RP) [page 205] and Clearing Processing (FS-PE-CP) [page
337].

More Information

Route [page 207]

Customer Agreement [page 231]

Value Date Agreement [page 244]

13.4.2.1 Managing Clearing Agreement Rule Sets

Use

You can manage clearing agreement rule sets as follows:

• Create a clearing agreement rule set

You can create a clearing agreement rule set by creating the first rule for a rule set in a clearing area. The
system then automatically creates a clearing agreement rule set.
• Change a clearing agreement rule set
You can change a clearing agreement rule set by adding, changing, or deleting rules in the rule set. In
addition, you can activate or deactivate rules in the rule set.
• Delete a clearing agreement rule set
You can delete a clearing agreement rule set by deleting all rules in the rule set.
• Display a clearing agreement rule set
You can display a clearing agreement rule set by displaying a clearing agreement associated with this rule
set.

Payment Engine (FS-PE)

222 PUBLIC Master Data
Prerequisites

To create, change, and delete a clearing agreement and its rule set:

• You have defined the release workflow in Customizing for Payment Engine under Routing Control
Release Clearing Agreement and Rule Set .
• You have the necessary rights to change and create a clearing agreement and its rule set for the selected
clearing area.

To display a clearing agreement and its rule set:

You have display rights for the selected clearing area.

Procedure

On the SAP Easy Access screen, choose Payment Engine Master Data Routing Control Manage Routes
and Clearing Agreements (transaction /PE1/RN), enter a clearing area, and continue.

 Note

You can show or hide the search area and navigation tree by choosing the Switch Overview Tree On/Off
pushbutton.

Creating Clearing Agreement Rule Sets

Creating Clearing Agreement

To create a clearing agreement, proceed as follows:

1. Choose the Clearing Agreement pushbutton, enter an ID for the new clearing agreement, and continue.
2. Enter data as required.
3. Save the object and trigger the release process by choosing the Release pushbutton.

 Note

You can also copy an existing clearing agreement on which you base your new clearing agreement.

Creating Clearing Agreement Rule

For more information, see Managing Clearing Agreement Rules [page 224].

When you save the rule, the system automatically creates the rule set.

Changing Clearing Agreement Rule Sets

1. From the navigation tree, double-click the clearing agreement associated with the rule set that you want to
change.
2. In change mode, you can change the clearing agreement in the business object screen area and the
clearing agreement rule set in the rules screen area.
For more information about the screen areas on the clearing agreement screen, see Clearing Agreement
[page 219] under Structure.

Payment Engine (FS-PE)

Master Data PUBLIC 223
  Note

You can show or hide the rule set by choosing the Set of Rules pushbutton.

3. Make the required changes.

You can create, change, and delete rules in the rule set. Furthermore, you can activate or deactivate rules in
the rule set.
For more information, see Managing Clearing Agreement Rules.
4. Save the object and trigger the release process by choosing the Release pushbutton.

 Note

You can process only objects with Released status. If the object is not released, the old rule applies.

Deleting Clearing Agreement Rule Sets

1. From the navigation tree, double-click a clearing agreement associated with the rule set that you want to
delete.

 Note

You can show or hide the rule set by choosing the Set of Rules pushbutton.

2. In change mode, choose the Delete Rule Set pushbutton to set all rules in the rule set to Flagged for
Deletion.

 Note

When you delete a rule set, the system also deletes all rules associated with the rule set.

3. Save the object and trigger the release process by choosing the Release pushbutton.

 Note

The object is actually deleted when it reaches the Released status.

Displaying Clearing Agreement Rule Sets

From the navigation tree, double-click the clearing agreement for which you want to display the rule set.

The clearing agreement details are displayed in the business object screen area. The clearing agreement rule
set is displayed in the rules screen area.

13.4.2.2 Managing Clearing Agreement Rules

Use

You can manage clearing agreement rules as follows:

• Create a clearing agreement rule

You can create a rule that is used during routing process to determine the clearing agreement.
• Change a clearing agreement rule

Payment Engine (FS-PE)

224 PUBLIC Master Data
 You can change the behavior in the clearing agreement determination by changing characteristics in the
rule. You can only change clearing agreement rules by changing a clearing agreement.
• Delete a clearing agreement rule
You can delete a clearing agreement rule by changing a clearing agreement.
• Display a clearing agreement rule
You can display a rule for a clearing agreement to see the characteristics of the rule that define its behavior.

Prerequisites

To create, change, and delete a clearing agreement and its rules:

• You have defined the release workflow in Customizing for Payment Engine under Routing Control
Release Clearing Agreement and Rule Set .
• You have the necessary rights to change and create a clearing agreement and its rules for the selected
clearing area.

To display a clearing agreement and its rules:

You have display rights for the selected clearing area.

Procedure

On the SAP Easy Access screen, choose Payment Engine Master Data Routing Control Manage Routes
and Clearing Agreements (transaction /PE1/RN), enter a clearing area, and continue.

 Note

You can show or hide the search area and navigation tree by choosing the Switch Overview Tree On/Off
pushbutton.

Creating Clearing Agreement Rules

1. From the navigation tree, double-click a clearing agreement associated with the clearing agreement rule
set where you want to add a rule.
2. In change mode, you can change the clearing agreement in the business object screen area and the
clearing agreement rules in the rules screen area.
For more information about the screen areas on the clearing agreement screen, see Clearing Agreement
[page 219] under Structure.

 Note

You can show or hide the rules by choosing the Set of Rules pushbutton.

3. Do one of the following:

• Create a new rule by choosing in the rules screen area.

The dynamic selection screen (rule maintenance) appears where you can choose the characteristics
for the rule.

Payment Engine (FS-PE)

Master Data PUBLIC 225
 • Copy an existing rule by choosing in the rules screen area.
4. Enter data as required.
5. Save the object and trigger the release process by choosing the Release pushbutton.

 Note

You can process only objects with Released status.

Changing Clearing Agreement Rules

1. From the navigation tree, double-click a clearing agreement associated with the clearing agreement rule
set where you want to change a rule.
2. In change mode, you can change the clearing agreement in the business object screen area and the
clearing agreement rules in the rules screen area.
For more information about the screen areas on the clearing agreement screen, see Clearing Agreement
under Structure.

 Note

You can show or hide the rules by choosing the Set of Rules pushbutton.

3. In the rules screen area, choose the rule that you want to change and choose .
The dynamic selection screen (rule maintenance) appears where you can choose the characteristics for
the rule.
4. Make the required changes.
5. Furthermore, you can do one of the following:

• Activate a rule in the rule set by choosing .

• Deactivate a rule in the rule set by choosing .

6. Save the object and trigger the release process by choosing the Release pushbutton.

 Note

You can process only objects with Released status. If the object is not released, the old rule applies.

Deleting Clearing Agreement Rules

1. From the navigation tree, double-click a clearing agreement associated with the clearing agreement rule
set that contains the rule to be deleted.
2. In change mode, you can change the clearing agreement in the business object screen area and the
clearing agreement rules in the rules screen area.
For more information about the screen areas on the clearing agreement screen, see Clearing Agreement
under Structure.

 Note

You can show or hide the rules by choosing the Set of Rules pushbutton.

3. In the rules screen area, choose the rule that you want to delete and choose .
The rule is selected for deletion.
4. Save the object and trigger the release process by choosing the Release pushbutton.

Payment Engine (FS-PE)

226 PUBLIC Master Data
  Note

You can delete only objects with Released status.

Displaying Clearing Agreement Rules

1. From the navigation tree, double-click the clearing agreement of which you want to display a rule.
The clearing agreement details are displayed in the business object screen area. The clearing agreement
rules are displayed in the rules screen area.
For more information about the screen areas on the clearing agreement screen, see Clearing Agreement
under Structure.

 Note

You can show or hide the rules by choosing the Set of Rules pushbutton.

2. Choose the rule that you want to display and choose .

The dynamic selection screen (rule maintenance) appears where you can check the details of the rule.

13.4.2.3 Release Object CA (Clearing Agreement)

Definition

A release object in Payment Engine used by the system to identify whether the editing of a clearing agreement
or clearing agreement rule set by an author or a processor is subject to release.

If the editing of the clearing agreement or its rule set is subject to release, the system generates a release
object CA (clearing agreement) as a work item that can be processed further by a supervisor or user
responsible for release in the Business Workplace.

Use

Customizing

In Customizing, you can define how many release steps the object must pass (for example, for dual or treble
control) and the conditions when the release workflow is carried out (for example, always, conditional by using
release attributes).

You make the settings for release object CA in Customizing for Payment Engine under Routing Control
Release Clearing Agreement and Rule Set in the following Customizing activities:

• Assign Release Procedure to Release Object

• Assign Standard Role to Release Steps
• Assign Workflow and Sub-Workflow to Release Procedure

Channel

Dialog

Payment Engine (FS-PE)

Master Data PUBLIC 227
Individual processing: transaction Manage Routes and Clearing Agreements (/PE1/RN)

The system checks whether the dialog processing of the clearing agreement or its rule set is subject to release,
and generates a work item for every release-relevant clearing agreement or clearing agreement rule set. If
a clearing agreement or its rule set is no longer subject to release after processing, the system deletes the
associated work item.

Business Application Programming Interface (BAPI)

Like during dialog processing, the system checks whether editing a clearing agreement or its rule set by using
BAPIs is subject to release and generates a work item for every release-relevant editing. If a clearing agreement
or its rule set is no longer subject to release after editing, the system deletes the associated work item.

Structure

You can edit release object CA as a work item in the Business Workplace. These methods can affect the status
of the clearing agreement. For more information, see Status and Release Status of Master Data Objects [page
229].

• Display
Choosing this pushbutton brings you to the dialog transaction Manage Routes and Clearing Agreements.
• Change
Choosing this pushbutton brings you to the dialog transaction Manage Routes and Clearing Agreements.
The system closes the old release workflow and triggers a new release process with the changed data. The
status of the new clearing agreement release object is initially For Release. This method in the Business
Workplace can change the status and release status of the clearing agreement as follows:
The system checks the changed item and generates a new work item if applicable and deletes the existing
work item.
• Display change documents
Choosing this pushbutton opens the dialog transaction Manage Routes and Clearing Agreements with
dialog box Display Change Documents of the clearing agreement.
• Release
This method in the Business Workplace can change the status and release status of the clearing
agreement as follows:
Editing the clearing agreement:

Before Release After Release

Status of the Clearing Release Status Status of the Clearing Release Status
Agreement Agreement

Inactive For Release Active Released

• Reject
Choosing this pushbutton rejects the change of the clearing agreement.

Payment Engine (FS-PE)

228 PUBLIC Master Data
 This method in the Business Workplace can change the status and release status of the clearing
agreement as follows:
Editing the clearing agreement:

Before Release After Release

Status of the Clearing Release Status Status of the Clearing Release Status
Agreement Agreement

Inactive For Release Active In Process

More Information

Clearing Agreement [page 219]

13.4.2.4 Status and Release Status of Master Data Objects

When you edit the following master data objects in SAP Payment Engine, the status and release status of the
object can change:

• Service level agreement and rule set for service level agreements
• Value date agreement and rule set for value date agreements
• Route and route rule set
• Clearing agreement and clearing agreement rule set
• Customer agreement and customer agreement rule set
• Exception control rule set

Payment Engine (FS-PE)

Master Data PUBLIC 229
The following graphic illustrates the possible statuses for all these objects:

Status and Release Status of a Master Data Object

 Note

To activate the creation or change of an object, always use the release pushbutton even if no release
workflow is set in Customizing for Payment Engine.

Related Information

Release Object SLA (Service Level Agreement) [page 261]

Release Object ROUTE (Route) [page 214]
Release Object CA (Clearing Agreement) [page 227]
Release Object CUSTAGR (Customer Agreement) [page 239]
Release Object CAGRASS (Assignment of General Customer Agreement) [page 241]

Payment Engine (FS-PE)

230 PUBLIC Master Data
Release Object EH (Exception Control Rule Set) [page 280]
Foreign Exchange (FX) [page 284]

13.4.3 Customer Agreement

Definition

A special agreement with a customer of a financial institution.

The customer agreement identifies the customer account or accounts that are relevant for the special
agreement; or the accounts can be defined by a customer service level agreement (SLA) and this SLA refers to
the customer agreement.

A customer agreement is used to group a set of internal clearing agreements (customer clearing agreements)
that are associated with a specific customer. Customer agreements can be defined below internal routes only.

Use

By using customer agreements, you can identify certain payments for certain accounts that are to be collected
before they are posted as one sum to an account. You can then provide the customer with an electronic advice
showing the details of the sum that the system posted to the account.

You use a customer agreement to group a set of internal clearing agreements with an association to a
customer. Customer agreements can be valid for one or more accounts of a customer:

• Specific customer agreement (type Other)

In most cases, you manage this customer agreement directly for one or more accounts of a specific
customer. The agreement is unique and cannot be used for other customers.

Customer clearing agreements created below an individual customer agreement are of clearing agreement
type Internal: Individual Service Level Agreement.

You can manage both customer agreements and their rule sets and customer clearing agreements and their
rules as follows:

On the SAP Easy Access screen, choose Payment Engine Master Data Routing Control Manage Routes
and Clearing Agreements (transaction /PE1/RN). For more information, see Managing Customer Agreement
Rule Sets [page 233] and Managing Customer Clearing Agreement Rules [page 236].

Structure

Customer Agreement Screen

Payment Engine (FS-PE)

Master Data PUBLIC 231
The customer agreement screen is organized in the following screen areas:

• Search area
You can enter a text to search for customer agreements currently loaded in the navigation tree. When you
run a search, a new node with the result is created in the tree.
• Navigation tree
Displays existing routes, clearing agreements, customer agreements, and customer clearing agreements
in a hierarchical structure.
• Business object
Displays details about the selected route, clearing agreement, customer agreement, or customer clearing
agreement organized on tab pages.

Customer Agreement Screen

Customer Agreement Details

Header Data

• Route information
Contains the route ID, its description, and the release status of the route to which the customer agreement
is assigned.
• Customer agreement information
Contains the customer agreement ID, its description, and the release status of the customer agreement.

Basic Data

On the customer agreement screen, you can find the following business object information.

• Type of customer agreement

There are the following types of customer agreement:
• General customer agreement
• Specific customer agreement
• Customer agreement status
A customer agreement can have the following customer agreement statuses:
• Active
• Inactive

Payment Engine (FS-PE)

232 PUBLIC Master Data
 • Flagged for deletion
• Bank customer
You can use this field to assign a customer agreement to a specific customer.
• Valid from and valid to
Indicates the validity of the customer agreement.
• Assigned Accounts tab page
You can specify different accounts of a specific customer.

Customer Clearing Agreement

For more information about the structure of customer clearing agreements, see Clearing Agreement [page
219] under Structure as these objects share the same structure.

Integration

Customer agreements are integrated in the Routing Control component. After determining a route, the system
searches for a customer agreement using either the customer service level agreement reference in the
payment item or the list of accounts assigned in the customer agreement:

• If a payment item is enriched with a reference to a customer SLA during enrichment and validation and this
SLA contains a customer agreement reference, the system uses this reference to determine the customer
agreement.
For more information, see Enrichment and Validation [page 311] and Service Level Agreement [page 256].
• If no reference from an SLA to a customer agreement is available, the system uses the account data in the
payment item to determine the customer agreement.

Once a customer agreement is determined, the system searches for a customer clearing agreement grouped
below this customer agreement. This customer clearing agreement specifies further processing of the
payment item. If the system cannot determine any route, customer agreement, and customer clearing
agreement, then a new search starts.

It is not mandatory to specify a customer agreement for route processing. The route and clearing agreement
combination is also valid. If the system cannot determine any customer agreement, an internal clearing
agreement is used to further process the payment item in Clearing Processing.

For more information about further processing, see Clearing Processing (FS-PE-CP) [page 337].

13.4.3.1 Managing Customer Agreement Rule Sets

Use

You can manage customer agreement rule sets as follows:

• Create a customer agreement rule set

You can create a customer agreement rule set by creating the first rule for a customer clearing agreement
grouped under the customer agreement in a clearing area. The system then automatically creates a
customer agreement rule set. You can add rules that determine which customer clearing agreement is to
be used.

Payment Engine (FS-PE)

Master Data PUBLIC 233
• Change a customer agreement rule set
You can change a customer agreement rule set by adding, changing, or deleting rules in the rule set. In
addition, you can activate or deactivate rules in the rule set.
• Delete a customer agreement rule set
You can delete a customer agreement rule set by deleting all rules in the rule set.
• Display a customer agreement rule set
You can display a customer agreement rule set by displaying a customer clearing agreement grouped
under that customer agreement.

Prerequisites

To create, change, and delete a customer agreement and its rule set:

• You have defined the release workflow in Customizing for Payment Engine under Routing Control
Release Customer Agreements .
• You have the necessary rights to change and create a customer agreement and its rule set for the selected
clearing area.

To display a customer agreement and its rule set:

You have display rights for the selected clearing area.

Procedure

On the SAP Easy Access screen, choose Payment Engine Master Data Routing Control Manage Routes
and Clearing Agreements (transaction /PE1/RN), enter a clearing area, and continue.

 Note

You can show or hide the search area and navigation tree by choosing the Switch Overview Tree On/Off
pushbutton.

Creating Customer Agreement Rule Sets

Creating Customer Agreement

1. Choose the Customer Agreement pushbutton, enter a route, an ID, and a type for the customer agreement,
and continue.
2. Enter data as required.
3. Save the object and trigger the release process by choosing the Release pushbutton.

 Note

You can process only objects with Released status.

Creating Customer Clearing Agreement

Payment Engine (FS-PE)

234 PUBLIC Master Data
1. From the navigation tree, double-click a customer agreement under which you want to create a customer
clearing agreement.
2. Choose the Clearing Agreement pushbutton, enter an ID, and continue.
You can also copy an existing clearing agreement on which you base your new clearing agreement.
3. Enter data as required.
4. Save the object and trigger the release process by choosing the Release pushbutton.

 Note

You can process only objects with Released status.

Creating Customer Clearing Agreement Rule

1. From the navigation tree, double-click a customer clearing agreement associated with the customer
agreement rule set where you want to add a rule.
2. In change mode, you can change the customer clearing agreement in the business object screen area and
the customer agreement rule set in the rules screen area.
For more information about the screen areas on the customer clearing agreement screen, see Customer
Agreement [page 231] under Structure.
3. Create a customer clearing agreement rule.
For more information, see Managing Customer Clearing Agreement Rules [page 236].
When you save the rule, the system automatically creates the rule set.

Changing Customer Agreement Rule Sets

1. From the navigation tree, double-click a customer clearing agreement that is grouped under the customer
agreement of the rule set that you want to change.
2. In change mode, you can change the customer clearing agreement in the business object screen area and
the customer agreement rule set in the rules screen area.
For more information about the screen areas on the customer clearing agreement screen, see Customer
Agreement under Structure.

 Note

You can show or hide the rule set by choosing the Set of Rules pushbutton.

3. Make the required changes.

You can create, change, and delete rules in the rule set. Furthermore, you can activate or deactivate rules in
the rule set.
For more information, see Managing Customer Clearing Agreement Rules.
4. Save the object and trigger the release process by choosing the Release pushbutton.

 Note

You can process only objects with Released status. If the object is not released, the old rule applies.

Deleting Customer Agreement Rule Sets

1. From the navigation tree, double-click a customer clearing agreement that is grouped under the customer
agreement of the rule set that you want to delete.

 Note

You can show or hide the rule set by choosing the Set of Rules pushbutton.

Payment Engine (FS-PE)

Master Data PUBLIC 235
2. In change mode, choose the Delete Rule Set pushbutton to set all rules in the rule set to Flagged for
Deletion.

 Note

When you delete a rule set, the system also deletes all rules associated with the rule set.

3. Save the object and trigger the release process by choosing the Release pushbutton.

 Note

The object is actually deleted when it reaches the Released status.

Displaying Customer Agreement Rule Sets

From the navigation tree, double-click the customer clearing agreement grouped under the customer
agreement of which you want to display the rule set.

The customer clearing agreement details are displayed in the business object screen area. The customer
agreement rule set is displayed in the rules screen area.

13.4.3.2 Managing Customer Clearing Agreement Rules

Use

You can manage customer clearing agreement rules as follows:

• Create a customer clearing agreement rule

You can create a rule that is used during routing process to determine the customer clearing agreement.
• Change a customer clearing agreement rule
You can change the behavior in the customer clearing agreement determination by changing
characteristics in the rule. You can only change customer clearing agreement rules by changing a
customer clearing agreement.
• Delete a customer clearing agreement rule
You can delete a customer clearing agreement rule by changing a customer clearing agreement.
• Display a customer clearing agreement rule
You can display a rule for a customer clearing agreement to see the characteristics of the rule that define
its behavior.

Prerequisites

To create, change, and delete a customer clearing agreement and its rules:

• You have defined the release workflow in Customizing for Payment Engine under Routing Control
Release Customer Agreements .
• You have the necessary rights to change and create a customer clearing agreement and its rules for the
selected clearing area.

Payment Engine (FS-PE)

236 PUBLIC Master Data
To display a customer clearing agreement and its rules:

You have display rights for the selected clearing area.

Procedure

On the SAP Easy Access screen, choose Payment Engine Master Data Routing Control Manage Routes
and Clearing Agreements (transaction /PE1/RN), enter a clearing area, and continue.

 Note

You can show or hide the search area and navigation tree by choosing the Switch Overview Tree On/Off
pushbutton.

Creating Customer Clearing Agreement Rules

1. From the navigation tree, double-click a customer clearing agreement associated with the customer
agreement rule set where you want to add a rule.
2. In change mode, you can change the customer clearing agreement in the business object screen area and
the customer agreement rule set in the rules screen area.
For more information about the screen areas on the customer clearing agreement screen, see Customer
Agreement [page 231] under Structure.

 Note

You can show or hide the rules by choosing the Set of Rules pushbutton.

3. Do one of the following:

• Create a new rule by choosing in the rules screen area.

The dynamic selection screen (rule maintenance) appears where you can choose the characteristics
for the rule.

• Copy an existing rule by choosing in the rules screen area.

4. Enter data as required.
5. Save the object and trigger the release process by choosing the Release pushbutton.

 Note

You can process only objects with Released status.

Changing Customer Clearing Agreement Rules

1. From the navigation tree, double-click a customer clearing agreement associated with the customer
agreement rule set where you want to change a rule.
2. In change mode, you can change the customer clearing agreement in the business object screen area and
the customer agreement rules in the rules screen area.
For more information about the screen areas on the customer clearing agreement screen, see Customer
Agreement under Structure.

 Note

You can show or hide the rules by choosing the Set of Rules pushbutton.

Payment Engine (FS-PE)

Master Data PUBLIC 237
3. In the rules screen area, choose the rule that you want to change and choose .
The dynamic selection screen (rule maintenance) appears where you can choose the characteristics for
the rule.
4. Make the required changes.
5. Furthermore, you can do one of the following:

• Activate a rule in the rule set by choosing .

• Deactivate a rule in the rule set by choosing .

6. Save the object and trigger the release process by choosing the Release pushbutton.

 Note

You can process only objects with Released status. If the object is not released, the old rule applies.

Deleting Customer Clearing Agreement Rules

1. From the navigation tree, double-click a customer clearing agreement associated with the customer
agreement rule set where you want to delete a rule.
2. In change mode, you can change the customer clearing agreement in the business object screen area and
the clearing agreement rule set in the rules screen area.
For more information about the screen areas on the customer clearing agreement screen, see Customer
Agreement under Structure.

 Note

You can show or hide the rules by choosing the Set of Rules pushbutton.

3. In the rules screen area, choose the rule that you want to delete and choose .
The rule is selected for deletion.
4. Save the object and trigger the release process by choosing the Release pushbutton.

 Note

You can delete only objects with Released status.

Displaying Customer Clearing Agreement Rules

1. From the navigation tree, double-click a customer clearing agreement associated with the customer
agreement rule set of which you want to display a rule.
The customer clearing agreement details are displayed in the business object screen area. The customer
clearing agreement rules are displayed in the rules screen area.
For more information about the screen areas on the customer clearing agreement screen, see Customer
Agreement under Structure.

 Note

You can show or hide the rules by choosing the Set of Rules pushbutton.

2. Choose the rule that you want to display and choose .

The dynamic selection screen (rule maintenance) appears where you can check the details of the rule.

Payment Engine (FS-PE)

238 PUBLIC Master Data
13.4.3.3 Release Object CUSTAGR (Customer Agreement)

Definition

A release object in Payment Engine (FS-PE) that the system uses to determine whether the editing of a
customer agreement by an author or a processor is subject to release.

If this is the case, the system generates release object CUSTAGR (customer agreement) as a work item that can
be processed by a supervisor or user responsible for release in the Business Workplace.

Use

Customizing

In Customizing, you can define how many release steps the object must pass (for example, for dual or treble
control) and the conditions when the release workflow is carried out (for example, always, conditional by using
release attributes).

You make the settings for release object CUSTAGR in Customizing for Payment Engine under Routing Control
Release Customer Agreements in the following Customizing activities:

• Assign Release Procedure to Release Object

• Assign Standard Role to Release Steps
• Assign Workflow and Sub-Workflow to Release Procedure

Channel

Dialog

Individual processing: transaction Manage Routes and Clearing Agreements (/PE1/RN)

The system checks whether the dialog processing of the customer agreement is subject to release and
generates a work item for every release-relevant customer agreement. If a customer agreement is no longer
subject to release after processing, the system deletes the associated work item.

Business Application Programming Interface (BAPI)

The system checks whether a customer agreement change needs to be released if you are using a BAPI to edit
it. If this is the case, the system generates a work item each time. If a customer agreement is no longer subject
to release after editing, the system deletes the associated work item.

Structure

You can edit release object CUSTAGR as a work item in the Business Workplace. These methods can affect
the status of the customer agreement. For more information, see Status and Release Status of Master Data
Objects [page 242].

• Display

Payment Engine (FS-PE)

Master Data PUBLIC 239
 This pushbutton opens the dialog transaction Manage Routes and Clearing Agreements.
• Change
This pushbutton opens the dialog transaction Manage Routes and Clearing Agreements. The system closes
the old release workflow and triggers a new release process with the changed data. The status of the new
customer agreement release object is initially For Release. This method in the Business Workplace can
change the status and release status of the customer agreement as follows:
The system checks the changed item and generates a new work item if applicable and deletes the existing
work item.
• Display change documents
This pushbutton opens the dialog transaction Manage Routes and Clearing Agreements with dialog box
Display Change Documents of the customer agreement.
• Release
This method in the Business Workplace can change the status and release status of the customer
agreement as follows:
Editing the customer agreement:

Before Release After Release

Status of the Customer Release Status Status of the Customer Release Status
Agreement Agreement

Inactive For Release Active Released

• Reject
Choosing this pushbutton rejects the change of the customer agreement.
This method in the Business Workplace can change the status and release status of the customer
agreement as follows:
Editing the customer agreement:

Before Release After Release

Status of the Customer Release Status Status of the Customer Release Status
Agreement Agreement

Inactive For Release Active In Process

More Information

Customer Agreement [page 231]

Payment Engine (FS-PE)

240 PUBLIC Master Data
13.4.3.4 Release Object CAGRASS (Assignment of General
Customer Agreement)

Definition

A release object in Payment Engine used by the system to identify whether the editing of a general customer
agreement by an author or a processor is subject to release.

If the editing of the general customer agreement is subject to release, the system generates a release object
CAGRASS (assignment of general customer agreement) as a work item that can be processed further by a
supervisor or user responsible for release in the Business Workplace.

Use

Customizing

In Customizing, you can define how many release steps the object must pass (for example, for dual or treble
control) and the conditions when the release workflow is carried out (for example, always, conditional by using
release attributes).

You make the settings for release object CAGRASS in Customizing for Payment Engine under Routing
Control Release Customer Agreements Assignment to General Customer Agreement in the following
Customizing activities:

• Assign Release Procedure to Release Object

• Assign Standard Role to Release Steps
• Assign Workflow and Sub-Workflow to Release Procedure

Channel

Dialog

Individual processing: transaction Manage Routes and Clearing Agreements (/PE1/RN)

The system checks whether the dialog processing of the general customer agreement is subject to release,
and generates a work item for every release-relevant general customer agreement. If a general customer
agreement is no longer subject to release after processing, the system deletes the associated work item.

Business Application Programming Interface (BAPI)

Like during dialog processing, the system checks whether editing a general customer agreement by using
BAPIs is subject to release and generates a work item for every release-relevant editing. If a general customer
agreement is no longer subject to release after editing, the system deletes the associated work item.

Structure

You can edit release object CAGRASS as a work item in the Business Workplace. These methods can affect the
status of the general customer agreement.

Payment Engine (FS-PE)

Master Data PUBLIC 241
More Information

Customer Agreement [page 231]

13.4.3.5 Status and Release Status of Master Data Objects

When you edit the following master data objects in SAP Payment Engine, the status and release status of the
object can change:

• Service level agreement and rule set for service level agreements
• Value date agreement and rule set for value date agreements
• Route and route rule set
• Clearing agreement and clearing agreement rule set
• Customer agreement and customer agreement rule set
• Exception control rule set

Payment Engine (FS-PE)

242 PUBLIC Master Data
The following graphic illustrates the possible statuses for all these objects:

Status and Release Status of a Master Data Object

 Note

To activate the creation or change of an object, always use the release pushbutton even if no release
workflow is set in Customizing for Payment Engine.

Related Information

Release Object SLA (Service Level Agreement) [page 261]

Release Object ROUTE (Route) [page 214]
Release Object CA (Clearing Agreement) [page 227]
Release Object CUSTAGR (Customer Agreement) [page 239]
Release Object CAGRASS (Assignment of General Customer Agreement) [page 241]

Payment Engine (FS-PE)

Master Data PUBLIC 243
Release Object EH (Exception Control Rule Set) [page 280]
Foreign Exchange (FX) [page 284]

13.4.4 Value Date Agreement

Definition

An object that specifies how the value date of a payment item is to be calculated.

Use

Value date agreements are used to determine value dates based on defined rules. This includes the use of
standard and configurable calendars at the level of the financial institution, the currency, and the clearing
partner (clearing or correspondent financial institution). In general, the system calculates the value date by
starting with a base value and adding a markup or subtracting a markdown. The base value as well as the
markup or markdown are determined from attributes of the payment order metaformat. By using flexible rule
sets, you can define value dating down to a single account level.

A value date agreement specifies the following:

• Whether a value date is necessary, and if so, how it is to be calculated as a:

• Posting date
• Fixed value date
• Recipient or ordering-party-dependent value date
• Whether fixed value dates in the incoming payment order are to be accepted.
• Whether fixed value dates are to be validated against a certain interval of allowed date ranges.
• Which calendars are to be taken into account when calculating the value date (route or clearing area
calendar, currency calendar, country calendar of all following institutions, the next institution or recipient
institution).

When determining the value date agreement, you have the same flexibility for rule sets as you have for
determining routes and clearing agreements. Each value date agreement is assigned to a rule set for value date
agreements. A rule set determines which value date agreement is relevant for a particular payment item. The
connection to the rule set determined as relevant for the payment item is stored in the associated clearing
agreement or route.

To determine a value date agreement, the system searches for the rule set for value date agreements defined
in the clearing agreement. If no valid rule is found at this level, the system validates the rule set for value date
agreements at route level.

If the system cannot determine any value date agreement, Routing Control raises an exception and hands the
error situation to Exception Control. This component defines an adequate response for the exception. For more
information, see Exception Control (FS-PE-EH) [page 265]. To avoid this kind of error, you can define a default
value date agreement by creating a rule without conditions. You attach this rule as the last rule in the rule set.

Payment Engine (FS-PE)

244 PUBLIC Master Data
You can also carry out a value split for ordering party items, that is, instead of creating one posting, the system
creates several items with corresponding value dates. The split is determined depending on the value dates of
the recipient items.

You can manage value date agreements and their rule sets as follows:

On the SAP Easy Access screen, choose Payment Engine Master Data Routing Control Manage Set of
Rules for Value Date (transaction /PE1/VA). For more information, see Managing Rule Sets for Value Date
Agreement [page 247] and Managing Value Date Agreement Rules [page 250].

Structure

Value Date Agreement Screen

The value date agreement screen is organized in the following screen areas:

• Search area
You can enter a text to search for value date agreements currently loaded in the navigation tree. When you
run a search, a new node with the result is created in the tree.
• Navigation tree
Displays existing rule sets and their associated value date agreements in a hierarchical structure.
• Business object
Displays details about the selected value date agreement organized on tab pages.
• Rules
Displays the rules in a rule set associated with the selected value date agreement.

Value Date Agreement Screen

Value Date Agreement Details

On the value date agreement screen, you can find the following business object information.

Header Data

Payment Engine (FS-PE)

Master Data PUBLIC 245
• Information about rule set for value date agreements
Contains the rule set ID for value date agreements, its description, and the release status of the rule set for
value date agreements to which the value date agreement is assigned.
• Value date agreement information
Contains the value date agreement ID, its description, and the release status of the value date agreement.

Basic Data

• Value date agreement status

A value date agreement can have the following value date agreement statuses:
• Active
• Inactive
• Flagged for deletion
• Value dating necessity
You can define one of the following options for value dating:
• Value Date Calculation
• No Value Dating
• Do Not Transfer Value Date to Forwarding System
• Value date split
Indicates whether a value date split is executed. The value date split creates multiple ordering party items
out of one ordering-party item to link different value dates of recipient items to the ordering party.
• Fixed value acceptance
Indicates whether the feeder system is allowed to submit a value date to Payment Engine.
• Value date interval check
Indicates whether an interval check is performed. The value date interval check indicates in which range a
determined value date must be located.
• Validity Area of Agreement group box
Indicates whether the value date agreement is valid for different kinds of payment items.
• Calendar Included for Calculation group box
Indicates the factory calendars to be used in the calculation and how to use them. For value date
calculation, only days that are defined as business days in all activated calendars of the value date
agreement can be used. If no calendar is activated in the clearing agreement, then the SAP basis calendar
is used, where all days are business days.
You can define:
• Whether the route calendar or clearing area calendar is used to calculate the value date.
• Whether a currency calendar is to be used for determining the value date and which country calendars of
the transaction chain are to be used for value date calculation.
• The working day rule, that is, whether and how the value date calculation is shifted if the calculated dates
are not business days.

Calculation Data

You can define or display how calculation is done based on the following fields:

• Base Value
Indicates the date and time that is used as a basis for value date calculation, for example posting date or
recipient item value date.
• Markup/Markdown
Indicates the time added to or subtracted from the base value.

Payment Engine (FS-PE)

246 PUBLIC Master Data
• Information for Intraday Calculation group box
Indicates whether an intraday option must be performed.

Interval Check

The tab page appears if you have activated the interval check on the Basic Data tab. You can define the limits
for the interval check (relative to the posting date) and the response to errors.

Integration

Value date agreements are integrated in the Routing Control component. You can specify a reference to a
rule set for value date agreements for each clearing agreement. In addition, you must specify a reference to
a rule set for value date agreements for each route. If you have assigned a route and a clearing agreement
to a payment item, the system searches for a value date agreement in the rule set defined for the clearing
agreement. Only if this search is unsuccessful, the rule set defined for the route is used.

With regard to rule sets, the following applies:

• A rule set for value date agreements consists of one or multiple rules.
• One rule refers to exactly one value date agreement. The same value date agreement can occur in several
rules.

For more information about rule sets, see Rule Set [page 188].

More Information

Route [page 207]

Clearing Agreement [page 219]

13.4.4.1 Managing Rule Sets for Value Date Agreement

Use

You can manage rule sets for value date agreement as follows:

• Create a rule set for value date agreement

You can create a rule set for value date agreement by creating the first rule for a rule set in a clearing area.
The system then automatically creates a rule set for value date agreement.
• Change a rule set for value date agreement
You can change a rule set for value date agreement by adding, changing, or deleting rules in the rule set. In
addition, you can activate or deactivate rules in the rule set.
• Delete a rule set for value date agreement
You can delete a rule set for value date agreement by deleting all rules in the rule set.

Payment Engine (FS-PE)

Master Data PUBLIC 247
• Display a rule set for value date agreement
You can display a rule set for value date agreement by displaying a value date agreement associated with
this rule set.

Prerequisites

To create, change, and delete a value date agreement and its rule set:

• You have defined the release workflow in Customizing for Payment Engine under Routing Control
Release Value Date Agreement and Set of Rules .
• You have the necessary rights to change and create a value date agreement and its rule set for the selected
clearing area.

To display a value date agreement and its rule set:

You have display rights for the selected clearing area.

Procedure

On the SAP Easy Access screen, choose Payment Engine Master Data Routing Control Manage Set of
Rules for Value Date (transaction /PE1/VA), enter a clearing area, and continue.

 Note

You can show or hide the search area and navigation tree by choosing the Switch Overview Tree On/Off
pushbutton.

Creating Rule Sets for Value Date Agreement

Creating Set of Rules for Value Date

1. Choose the Set of Rules for Value Date pushbutton, enter an ID for the new rule set, and continue.
You can also copy an existing rule set for value date agreement on which you base your new rule set for
value.
2. Enter data as required.
3. Save the object and trigger the release process by choosing the Release pushbutton.

 Note

You can process only objects with Released status.

Creating Value Date Agreement

1. From the navigation tree, double-click a rule set for value date agreement under which you want to create a
value date agreement.
2. Choose the Value Date Agreement pushbutton, enter the ID of the rule set for value date agreement under
which the new value date agreement shall be grouped, enter an ID for the value date agreement, and
continue.

Payment Engine (FS-PE)

248 PUBLIC Master Data
 You can also copy an existing value date agreement on which you base your new value date agreement.
3. Enter data as required.
4. Save the object and trigger the release process by choosing the Release pushbutton.

 Note

You can process only objects with Released status.

Creating Value Date Agreement Rule

Create a value date agreement rule.

For more information, see Managing Value Date Agreement Rules [page 250].

When you save the rule, the system automatically creates the rule set.

Changing Rule Sets for Value Date Agreement

1. From the navigation tree, double-click the value date agreement that is grouped under the rule set for value
date agreement that you want to change.
2. In change mode, you can change the value date agreement in the business object screen area and the rule
set for value date agreement in the rules screen area.
For more information about the screen areas on the value date agreement screen, see Value Date
Agreement [page 244] under Structure.

 Note

You can show or hide the rule sets by choosing the Set of Rules pushbutton.

3. Make the required changes.

You can create, change, and delete rules in the rule set. Furthermore, you can activate or deactivate rules in
the rule set.
For more information, see Managing Value Date Agreement Rules.
4. Save the object and trigger the release process by choosing the Release pushbutton.

 Note

You can process only objects with Released status. If the object is not released, the old rule applies.

Deleting Rule Sets for Value Date Agreement

1. From the navigation tree, double-click a value date agreement that is grouped under the rule set for value
date agreement that you want to delete.

 Note

You can show or hide the rule set by choosing the Set of Rules pushbutton.

2. In change mode, choose to set all rules in the rule set to Flagged for Deletion.

 Note

When you delete a rule set, the system also deletes all rules associated with the rule set.

3. Save the object and trigger the release process by choosing the Release pushbutton.

Payment Engine (FS-PE)

Master Data PUBLIC 249
  Note

The object is actually deleted when it reaches the Released status.

Displaying Rule Sets for Value Date Agreement

From the navigation tree, double-click the value date agreement grouped under the rule set for value date
agreement that you want to display.

The value date agreement details are displayed in the business object screen area. The rule set for value date
agreement is displayed in the rules screen area.

13.4.4.2 Managing Value Date Agreement Rules

Use

You can manage value date agreement rules as follows:

• Create a value date agreement rule

You can create a rule that is used during value dating to determine the value date.
• Change a value date agreement rule
You can change the behavior in the value date determination by changing characteristics in the rule. You
can only change value date agreement rules by changing a value date agreement.
• Delete a value date agreement rule
You can delete a value date agreement rule by changing a value date agreement.
• Display a value date agreement rule
You can display a rule for a value date agreement to see the characteristics of the rule that define its
behavior.

Prerequisites

To create, change, and delete a value date agreement and its rules:

• You have defined the release workflow in Customizing for Payment Engine under Routing Control
Release Value Date Agreement and Set of Rules .
• You have the necessary rights to change and create a value date agreement and its rules for the selected
clearing area.

To display a value date agreement and its rules:

You have display rights for the selected clearing area.

Payment Engine (FS-PE)

250 PUBLIC Master Data
Procedure

On the SAP Easy Access screen, choose Payment Engine Master Data Routing Control Manage Set of
Rules for Value Date (transaction /PE1/VA), enter a clearing area, and continue.

 Note

You can show or hide the search area and navigation tree by choosing the Switch Overview Tree On/Off
pushbutton.

Creating Value Date Agreement Rules

1. From the navigation tree, double-click the value date agreement associated with the rule set where you
want to add a rule
2. In change mode, you can change the value date agreement in the business object screen area and the
value date agreement rule set in the rules screen area.
For more information about the screen areas on the value date agreement screen, see Value Date
Agreement [page 244] under Structure.

 Note

You can show or hide the rules by choosing the Set of Rules pushbutton.

3. Do one of the following:

• Create a new rule by choosing in the rules screen area.

The dynamic selection screen (rule maintenance) appears where you can choose the characteristics
for the rule.

• Copy an existing rule by choosing in the rules screen area.

4. Enter data as required.
5. Save the object and trigger the release process by choosing the Release pushbutton.

 Note

You can process only objects with Released status.

Changing Value Date Agreement Rules

1. From the navigation tree, double-click the value date agreement associated with the rule set where you
want to change a rule.
2. In change mode, you can change the value date agreement in the business object screen area and the
value date agreement rules in the rules screen area.
For more information about the screen areas on the value date agreement screen, see Value Date
Agreement under Structure.

 Note

You can show or hide the rules by choosing the Set of Rules pushbutton.

3. In the rules screen area, choose the rule that you want to change and choose .
The dynamic selection screen (rule maintenance) appears where you can choose the characteristics for
the rule.

Payment Engine (FS-PE)

Master Data PUBLIC 251
4. Make the required changes.
5. You can do one of the following:

• Activate a rule in the rule set by choosing .

• Deactivate a rule in the rule set by choosing .

6. Save the object and trigger the release process by choosing the Release pushbutton.

 Note

You can process only objects with Released status. If the object is not released, the old rule applies.

Deleting Value Date Agreement Rules

1. From the navigation tree, double-click a value date agreement associated with the value date agreement
rule set where you want to delete a rule.
2. In change mode, you can change the value date agreement in the business object screen area and the
value date agreement rule set in the rules screen area.
For more information about the screen areas on the value date agreement screen, see Value Date
Agreement under Structure.

 Note

You can show or hide the rules by choosing the Set of Rules pushbutton.

3. In the rules screen area, choose the rule that you want to delete and choose .
The rule is selected for deletion.
4. Save the object and trigger the release process by choosing the Release pushbutton.

 Note

You can delete only objects with Released status.

Displaying Value Date Agreement Rules

1. From the navigation tree, double-click the value date agreement associated with the rule set of which you
want to display a rule.
The value date agreement details are displayed in the business object screen area. The value date
agreement rules are displayed in the rules screen area.
For more information about the screen areas on the value date agreement screen, see Value Date
Agreement under Structure.

 Note

You can show or hide the rules by choosing the Set of Rules pushbutton.

2. Choose the rule that you want to display and choose .

The dynamic selection screen (rule maintenance) appears where you can check the details of the rule.

Payment Engine (FS-PE)

252 PUBLIC Master Data
13.4.4.3 Release Object VA (Value Date Agreement)

Definition

A release object in Payment Engine used by the system to identify whether the editing of a value date
agreement or a rule set for value date agreements by an author or a processor is subject to release.

If the editing of the value date agreement or its rule set is subject to release, the system generates a release
object VA (value date agreement) as a work item that can be processed further by a supervisor or user
responsible for release in the Business Workplace.

Use

Customizing

In Customizing, you can define how many release steps the object must pass (for example, for dual or treble
control) and the conditions when the release workflow is carried out (for example, always, conditional by using
release attributes).

You make the settings for release object VA in Customizing for Payment Engine under Routing Control
Release Value Date Agreement and Set of Rules in the following Customizing activities:

• Assign Release Procedure to Release Object

• Assign Standard Role to Release Steps
• Assign Workflow and Sub-Workflow to Release Procedure

Channel

Dialog

Individual processing: transaction Manage Set of Rules for Value Date (/PE1/RN)

The system checks whether the dialog processing of the value date agreement or its rule set is subject to
release and generates a work item for every release-relevant value date agreement. If a value date agreement
or its rule set is no longer subject to release after processing, the system deletes the associated work item.

Business Application Programming Interface (BAPI)

Like during dialog processing, the system checks whether editing a value date agreement or its rule set by
using BAPIs is subject to release and generates a work item for every release-relevant editing. If a value date
agreement or its rule set is no longer subject to release after editing, the system deletes the associated work
item.

Structure

You can edit release object VA as a work item in the Business Workplace. These methods can affect the status
of the value date agreement. For more information, see Status and Release Status of Master Data Objects
[page 255].

Payment Engine (FS-PE)

Master Data PUBLIC 253
• Display
Choosing this pushbutton brings you to the dialog transaction Manage Set of Rules for Value Date.
• Change
Choosing this pushbutton brings you to the dialog transaction Manage Set of Rules for Value Date. The
system closes the old release workflow and triggers a new release process with the changed data. The
new release object status for the value date agreement is initially For Release. This method in the Business
Workplace can change the status and release status of the value date agreement as follows:
The system checks the changed item and generates a new work item if applicable and deletes the existing
work item.
• Display change documents
Choosing this pushbutton opens the dialog transaction Manage Set of Rules for Value Date with dialog box
Display Change Documents of the value date agreement.
• Release
This method in the Business Workplace can change the status and release status of the value date
agreement as follows:
Editing the value date agreement:

Before Release After Release

Status of the Value Date Release Status Status of the Value Date Release Status
Agreement Agreement

Inactive For Release Active Released

• Reject
Choosing this pushbutton rejects the change of the value date agreement.
This method in the Business Workplace can change the status and release status of the value date
agreement as follows:
Editing the value date agreement:

Before Release After Release

Status of the Value Date Release Status Status of the Value Date Release Status
Agreement Agreement

Inactive For Release Active In Process

More Information

Value Date Agreement [page 244]

Payment Engine (FS-PE)

254 PUBLIC Master Data
13.4.4.4 Status and Release Status of Master Data Objects

When you edit the following master data objects in SAP Payment Engine, the status and release status of the
object can change:

• Service level agreement and rule set for service level agreements
• Value date agreement and rule set for value date agreements
• Route and route rule set
• Clearing agreement and clearing agreement rule set
• Customer agreement and customer agreement rule set
• Exception control rule set

The following graphic illustrates the possible statuses for all these objects:

Status and Release Status of a Master Data Object

Payment Engine (FS-PE)

Master Data PUBLIC 255
  Note

To activate the creation or change of an object, always use the release pushbutton even if no release
workflow is set in Customizing for Payment Engine.

Related Information

Release Object SLA (Service Level Agreement) [page 261]

Release Object ROUTE (Route) [page 214]
Release Object CA (Clearing Agreement) [page 227]
Release Object CUSTAGR (Customer Agreement) [page 239]
Release Object CAGRASS (Assignment of General Customer Agreement) [page 241]
Release Object EH (Exception Control Rule Set) [page 280]
Foreign Exchange (FX) [page 284]

13.5 Service Level Agreement

Definition

An agreement between a financial institution and its customers that defines various conditions for senders of
payment orders.

This information is relevant to the enrichment and validation process, in particular, the enrichment of payment
transaction data and the clearing and settlement process. It also defines how the system processes payment
orders and payment items.

Use

You use service level agreements (SLAs) to define different values and validation criteria (for example, the error
percentage allowed) that are used in the enrichment and validation process. SLAs also ensure that payment
orders and payment items meet the requirements of a financial institution based on negotiations between the
account managers and the customers of the financial institution.

You can set the system up so that the payment order is also sent to exception handling if the percentage of
incorrect recipient items exceeds a threshold value that you define.

The following SLA types are used for each payment item:

• Clearing area SLA

A generic SLA stored at clearing area (branch) level.
You use clearing area SLAs to stipulate requirements (formal and material) that payment orders and
payment items have to comply with to ensure seamless payment processing in SAP Payment Engine.

Payment Engine (FS-PE)

256 PUBLIC Master Data
• Customer segment SLA
An SLA stored at customer segment level.
You use customer segment SLAs to define special conditions for groups of customers, such as VIPs,
high-income earners, or families. Assignments to segments are done through accounts or wildcards.
• Customer group SLA
An SLA stored at customer group level.
You use customer group SLAs to define special conditions for groups, such as corporate groups.
• Customer SLA
An SLA stored at customer level that is only applicable to individual customers.
You use customer SLAs to define special customer requirements or special customer agreements with the
financial institution.

Many of the formal and material checks depend on the SLA determined for the payment item that is
being processed. The SLA defines not only the checks that the system performs but also process-specific
information that is used in the actual processing of the payment items.

You can define the following conditions or restrictions in SLAs:

• Specified payment products and channels

A customer is only allowed to use certain channels and payment products.
• Payment amount limit
For certain payment products, a customer must not exceed certain amounts when sending payment
orders to a financial institution.

 Example

In the context of wholesale banking, a customer cannot send domestic payment orders for amounts
that exceed €10,000,000. This limit is not comparable to the credit limit or the actual amount available
to the customer on the account that is stored in the authorization or credit-limit-check application.

• Cut-off time
A customer who sends payment orders to SAP Payment Engine has to comply with certain cut-off times to
ensure that the financial institution can process the payment within a given business day.

 Example

A customer is limited to sending retail mass payments before 11:00 a.m. if the financial institution is to
guarantee processing within the same business day.

• Transaction type lock

Certain transaction types can be locked for certain customers even though these customers are allowed to
use the payment product and channel.
You can also restrict certain transactions in certain bank countries as part of country risk management.
Depending on your settings, the system validates recipient items, checking first the settings for the
customer SLA, then the segment SLA, and then the clearing SLA. You can specify what is to happen if a
recipient item fails the validation and goes to exception handling. There, the system determines the defined
response for the error, for example, whether to send items to postprocessing, or ignore them.

 Example

A customer may be allowed to send salary payments by using the corporate gateway channel but may
not be allowed to send direct debits using this channel.

Payment Engine (FS-PE)

Master Data PUBLIC 257
 In country risk management, a bank might decide that a particular country is too risky for credit
transfers.

• Correspondence
You can define or block correspondence recipients. The different correspondence types are triggered by
the specific processes in SAP Payment Engine.
• Foreign Exchange
You can make settings for foreign exchange. You can define rules for account determination, country-
specific conversion (that is, transaction currency in recipient-specific country currency), and rate
adjustment.
• Charges and charge limits
You can define rulesets that determine how charges are processed. These rulesets use the financial
conditions in the SAP component Financial Conditions (CA-FIM-FCO).
• Instruction keys
You can specify whether a given instruction key (code word from input file) is allowed or not allowed.
• Country restriction
You can specify that certain countries cannot receive transfers.

During SLA determination, attributes are considered from the specific SLA (that is, customer SLA). If an
attribute is not specified at that level, the next higher level is checked to see if the attribute is specified there,
and so on (that is, first the customer group SLA, then the customer segment SLA, and finally the clearing area
SLA). This does not, however, apply to correspondence settings. Correspondence attributes of all SLA levels
are taken into account. If, for example, correspondence is blocked at a higher (SLA) level, rules on lower levels
for the same recipient are overruled.

You manage SLAs as follows:

On the SAP Easy Access screen, choose Payment Engine Master Data Service Level Agreements
Manage Service Level Agreements (transaction /PE1/SLA). For more information, see Managing Service
Level Agreements [page 260].

Structure

An SLA is similar to a route or a clearing agreement in that it specifies information that determines how the
system processes payments.

An SLA comprises the following:

• Basic Data tab page

Displays basic data such as the SLA status and type, and information about the customer, such as
assigned accounts and business partner IDs.
• SLA General tab page
Displays additional information required for the enrichment and validation process and the clearing and
settlement process. This enables you to lock customer SLAs, so that the system sends all payment orders
for the customer to exception handling.
You can enable the functions and tab pages for foreign conversion, charges, and correspondence.
• Submission Data tab page
Displays a combination of channel, medium, and format. Payment orders that match the defined filter
options are enriched with the SLA information.

Payment Engine (FS-PE)

258 PUBLIC Master Data
 You can specify whether a given instruction key (code word from input file) is allowed or not allowed.
• Order Type Data tab page
Displays the formal and material checks defined in the SLA that are applied to payment orders of the
payment order type specified in this filter and also provides a check of the percentage of items with errors.
• Trans Type Data tab page
Displays the defined formal and material checks defined in the SLA that are applied to the payment orders
with payment items of the transaction type specified in this filter.
In the Country Restrictions group box, you can specify that a country cannot receive bank transfers. You do
this by specifying either the transaction type or group, and the country, and then selecting the Country Not
Allowed checkbox.
• Foreign Exchange tab page
Displays options and rule sets for Foreign Exchange (FX) transactions.
You can change Foreign Exchange (FX) rates. For more information, see Foreign Exchange (FX) [page 284].
• Charges tab page
Displays options to manage charges.
You can define rule sets on how to calculate, process and settle charges. For example, charges applied to
an individual customer can be reduced or waived.
• Correspondence tab page
Displays the correspondence options and rules, such as correspondence type, role, and recipient.
• Admin Data tab page
Displays the name of the creation, change, and release user with the date and time.

Integration

SLAs are integrated in enrichment and validation checks and in the clearing and settlement process to perform
additional checks of all payment orders and payment items for which the system finds an applicable SLA.

If a condition is not met in an SLA, SAP Payment Engine automatically triggers exception handling to evaluate
the error and determine an appropriate response.

Related Information

Exception Control (FS-PE-EH) [page 265]

Enrichment and Validation (FS-PE-EV) [page 311]
Enrichment and Validation Check [page 313]

Payment Engine (FS-PE)

Master Data PUBLIC 259
13.5.1 Managing Service Level Agreements

You manage service level agreements (SLAs) to define different conditions or restrictions for payment
transactions that are relevant to the enrichment and validation process and the clearing and settlement
process.

Prerequisites

To display an SLA:

You have display rights for the selected clearing area.

To create and change an SLA:

• You have defined the release workflow in Customizing for Payment Engine under Payment Order SLA
Release for SLA .
• You have the necessary rights to change and create an SLA for the selected clearing area.
• You have defined the number range for SLAs for the selected clearing area in Customizing for Payment
Engine under Payment Order SLA Maintain Number Ranges for SLAs .

Context

To manage SLAs, you can do the following:

• Display an existing SLA

• Create a new SLA of any type (clearing area, customer segment, customer group, or customer)
• Change an existing SLA
• Delete an SLA

 Note

These features are also available by means of Business Application Programming Interfaces (BAPIs). You
can use the corresponding BAPIs to create, change, or delete one or more SLAs without the graphical user
interface.

Procedure

1. On the SAP Easy Access screen, choose Payment Engine Master Data Service Level Agreements
Manage Service Level Agreements (transaction /PE1/SLA), enter a clearing area, and continue.
You can show or hide the search area and navigation tree by choosing the Switch Overview Tree On/Off
pushbutton.

Payment Engine (FS-PE)

260 PUBLIC Master Data
2. To create an SLA:
a. Choose the Create SLA pushbutton, choose the SLA type and, if necessary, the customer accounts or
customer segment.
You use customer segments to group customers that have similar characteristics and requirements,
such as students.
a. Enter additional information about the intended purpose of the SLA, such as additional locks, affected
customer accounts, or transactions types.
b. Save the object and trigger the release process by choosing the Release pushbutton.

You can also create SLAs by copying an existing service level agreement by choosing and entering a
new name for the copy of the existing service level agreement.
3. To display, change, or delete a service level agreement:
a. From the navigation tree, double-click the SLA you want to display, change, or delete. All details and
settings for the SLA are displayed on different tab pages. The tab pages that are available depend on
the type of SLA that you display.
4. To change an SLA:
a. In change mode, change the additional information about the intended purpose of the SLA.
b. Save the object and trigger the release process by choosing the Release pushbutton.
5. The SLA is removed from the navigation tree but remains in the Payment Engine database where it is set to
Flagged for Deletion when the archiving process takes place.

• For more information, see Archiving (FS-PE-ARC) [page 420].

Results

When you change an SLA, the system performs formal checks on the SLA such as accuracy checks of the IBAN
or account numbers or the consistency of the selected filters (transaction types, payment order types). If the
checks are successful, the SLA is saved and stored with the status Release In Process.

13.5.2 Release Object SLA (Service Level Agreement)

Definition

A release object in Payment Engine used by the system to identify whether the editing of a service level
agreement by an author or a processor is subject to release.

If the editing of the service level agreement is subject to release, the system generates a release object SLA
(service level agreement) as a work item that can be processed further by a supervisor or user responsible for
release in the Business Workplace.

Payment Engine (FS-PE)

Master Data PUBLIC 261
Use

Customizing

In Customizing, you can define how many release steps the object must pass (for example, for dual or treble
control) and the conditions when the release workflow is carried out (for example, always, conditional by using
release attributes).

You make the settings for release object SLA in Customizing for Payment Engine under Payment Order SLA
Release for SLA in the following Customizing activities:

• Assign Release Procedure to Release Object

• Assign Standard Role to Release Steps
• Assign Workflow and Sub-Workflow to Release Procedure

Channel

Dialog

Individual processing: transaction Manage Service Level Agreements (/PE1/SLA)

The system checks whether the dialog processing of the service level agreement is subject to release, and
generates a work item for every release-relevant service level agreement. If a service level agreement is no
longer subject to release after processing, the system deletes the associated work item.

Business Application Programming Interface (BAPI)

Like during dialog processing, the system checks whether editing a service level agreement by using BAPIs is
subject to release and generates a work item for every release-relevant editing. If a service level agreement is
no longer subject to release after editing, the system deletes the associated work item.

Structure

You can edit release object SLA as a work item in the Business Workplace. These methods can affect the status
of the service level agreement. For more information, see Status and Release Status of Master Data Objects
[page 255].

• Display
Choosing this pushbutton brings you to the dialog transaction Manage Service Level Agreements.
• Change
Choosing this pushbutton brings you to the dialog transaction Manage Service Level Agreements. The
system closes the old release workflow and triggers a new release process with the changed data. The new
release object status for the service level agreement is initially For Release. This method in the Business
Workplace can change the status and release status of the service level agreement as follows:
The system checks the changed item and generates a new work item if applicable and deletes the existing
work item.
• Display change documents
Choosing this pushbutton opens the dialog transaction Manage Service Level Agreements with dialog box
Display Change Documents of the service level agreement.
• Release

Payment Engine (FS-PE)

262 PUBLIC Master Data
 This method in the Business Workplace can change the status and release status of the service level
agreement as follows:
Editing the service level agreement:

Before Release After Release

Status of the Service Level Release Status Status of the Service Level Release Status
Agreement Agreement

Inactive For Release Active Released

• Reject
Choosing this pushbutton rejects the change of the service level agreement.
This method in the Business Workplace can change the status and release status of the service level
agreement as follows:
Editing the service level agreement:

Before Release After Release

Status of the Service Level Release Status Status of the Service Level Release Status
Agreement Agreement

Inactive For Release Active In Process

More Information

Service Level Agreement [page 256]

13.5.3 Status and Release Status of Master Data Objects

When you edit the following master data objects in SAP Payment Engine, the status and release status of the
object can change:

• Service level agreement and rule set for service level agreements
• Value date agreement and rule set for value date agreements
• Route and route rule set
• Clearing agreement and clearing agreement rule set
• Customer agreement and customer agreement rule set
• Exception control rule set

Payment Engine (FS-PE)

Master Data PUBLIC 263
The following graphic illustrates the possible statuses for all these objects:

Status and Release Status of a Master Data Object

 Note

To activate the creation or change of an object, always use the release pushbutton even if no release
workflow is set in Customizing for Payment Engine.

Related Information

Release Object SLA (Service Level Agreement) [page 261]

Release Object ROUTE (Route) [page 214]
Release Object CA (Clearing Agreement) [page 227]
Release Object CUSTAGR (Customer Agreement) [page 239]
Release Object CAGRASS (Assignment of General Customer Agreement) [page 241]

Payment Engine (FS-PE)

264 PUBLIC Master Data
Release Object EH (Exception Control Rule Set) [page 280]
Foreign Exchange (FX) [page 284]

13.6 Exception Control (FS-PE-EH)

Use

You use this component to define business rules that determine suitable response types for errors that occur
during straight-through processing (STP) and file handling. End-to-end payment processing is divided into a
sequence of logical processing steps. If the system finds errors in one of these steps that would prevent further
processing of a payment, then a suitable response is required. Payment Engine provides flexible functions
for exception handling, thus enabling financial institutions to configure control over the possible responses to
exceptions.

Integration

Exception Control handles all situations in payment order processing and payment item processing that
diverge from straight-through processing. Likewise, this component handles errors in File Handler that may
result in the creation of a dummy order. Furthermore, errors occurring during transfer by feeder systems and
outbound conversion are processed in exception handling.

The following components of Payment Engine are linked to Exception Control:

• File Handler (for Input Manager and Output Manager)

For more information, see File Handler (FS-PE-FH) [page 289].
• Payment Processing (in particular, enrichment and validation)
For more information, see Payment Processing (FS-PE-POP) [page 309].
• Routing Control
For more information, see Routing Control (FS-PE-RP) [page 205].
• Clearing Processing
For more information, see Clearing Processing (FS-PE-CP) [page 337].

Payment Engine directly handles exceptions during payment processing using the payment order management
transaction:

On the SAP Easy Access screen, choose Payment Engine Payment Order Management Edit Payment
Orders (Expert) (transaction /PE1/PO_EXPERT).

When you process a payment order, you can define whether Exception Control is to be used if an error occurs.
If Exception Control is used, exceptions related to processed payment orders and items are listed on tab pages
in the payment order management transaction. The exceptions are grouped on the Exception tab page of the
payment order or the Exception tab page of its payment items as an error vector. For more information, see
Payment Order and Payment Item Overview [page 375].

Payment Engine (FS-PE)

Master Data PUBLIC 265
Features

If an error occurs in any of the Payment Engine components that are linked to Exception Control, the system
stops the process that was being executed at that moment and transfers the error to Exception Control.

Exception Control recognizes the position where the process was stopped by the following parameters:

• Process identifier that specifies the stopped process

• Object category that was being processed
• Exception Control phase within the process
• Error check that specifies the failed Exception Control phase with accuracy

Exception Control is based on user-definable rule sets that identify which response is preferred in a certain
error situation. These rule sets can be based on attributes of the Payment Engine metaformat available in rule
maintenance. According to their assigned response type, the rules determine whether a check result leads to
termination of processing and whether follow-up actions need to be carried out on the payment order or a
payment item. You can define response types in Customizing based on predefined response categories. For
more information, see Response Category [page 267] and Response Type [page 269].

If the system has posted the ordering party item of a payment order, but the recipient items have to be
returned, a response type defined in Customizing can initiate the return of the payment. This type of payment
return is called an active return. For more information, see Processing of Active Returns [page 285].

A plausibility function in Exception Control ensures that only relevant responses can be defined for a specific
error situation. This means that certain error situations can only be linked to certain responses depending
on the process in question, the object category, and the Exception Control phase. You can set any permitted
response depending on these parameters. For more information, see Exception Control Rule Set [page 272].

If the response type causes the process in end-to-end payment processing to be continued, Exception Control
ensures that the process continues from the correct position with the correct parameters. Depending on the
response type, the object in question (payment order or payment item) can be resubmitted to end-to-end
payment processing at different positions: Either directly from the position where the transfer took place or
at the beginning of the process during end-to-end payment processing from which the transfer took place, for
example, payment processing or clearing and settlement.

After the system performs the response, the system checks and determines the following:

• If the response has been performed successfully, processing within Exception Control ends for the
business object in question.
• If it is not possible to perform a response, the system triggers an end response type to be carried out.

More Information

End-to-End Payment Processing [page 98]

Payment Engine (FS-PE)

266 PUBLIC Master Data
13.6.1 Response Category

Definition

A predefined classification of basic actions that the system performs when a payment order or payment item
cannot be processed.

Use

Response Categories for Payment Orders

Payment Engine provides the following response categories for payment orders:

• 01 Postprocessing of payment order

You can make manual changes to the payment order in accordance with the field selection control. The
system can resubmit the payment order automatically for straight-through processing. If the processing
period is exceeded, an end response type is determined.
• 02 Rejection of payment order
Processing of the payment order stops. The system rejects or reverses the payment order, depending on
the processing status.
• 04 Automatic postprocessing of payment order
Similar to the response for postprocessing; however, the payment order can be fixed and reprocessed by a
different system so that it can be resubmitted for straight-through processing externally.
• 05 Request payment order authorization
Processing of the payment item stops. In the case of an ordering party item, processing of the whole
payment order stops and the system requests authorization for the payment item to an external
authorization system. The external system can forward feedback about the authorization to Payment
Engine and the external system can trigger processing of the payment item to be continued.

 Note

The enrichment and validation process in Payment Processing determines the following events:

• Whether an authorization for a payment order is indicated.

• Whether a lock is stored in the associated service level agreement.
• Whether a configurable amount limit has been exceeded, even with existing authorization.

For these events, Exception Control requests payment order authorization. For more information, see
Enrichment and Validation [page 311].

• 07 Reprocessing of outgoing payment order

An offset clearing is posted, a failed transaction is copied to a new outgoing order and can be processed
again.
• 08 Resubmission of outgoing payment order
You can make manual changes to failed transactions. Afterwards, you can send them out. No clearing
offset is made.
• 99 Further processing

Payment Engine (FS-PE)

Master Data PUBLIC 267
 The system ignores the error and resubmits the payment order for straight-through processing. For more
information, see End-to-End Payment Processing [page 98].

Response Categories for Payment Items

Payment Engine provides the following response categories for payment items:

• 11 Postprocessing of payment item

You can make manual changes to the payment item in accordance with the field selection control. You can
resubmit the payment item for straight-through processing.
• 12 Return payment item
Processing of the payment item stops. The system performs a corresponding posting to the ordering party.
For more information, see Processing of Active Returns [page 285].
• 13 Redirection of payment item
The following redirection categories are possible:
• Account substitution
The system substitutes the account of a payment item with a different account using an account
symbol.
• No account substitution
This redirection category does not involve any change of account. The system sets an indicator and
rerouting takes place in Clearing Processing based on the setting of this indicator.
• Transfer posting
The system posts a recipient item to the ordering party account. The purpose is to cancel the effect of
an already posted ordering party item by posting the money back to the ordering party account.
• 14 Automatic postprocessing of payment item
Similar to the response for postprocessing; however, the payment item can be fixed and reprocessed by a
different system so that it can be resubmitted for straight-through processing externally.
• 15 Reroute transaction type
You can define a new transaction type for the payment item in Customizing.
• 16 Active return payment item
The system returns the recipient item (of a payment order where the ordering party item has already been
posted) to the account of the ordering party. For more information, see Processing of Active Returns [page
285].
• 17 Request payment item authorization
Processing of the payment item stops. In the case of an ordering party item, processing of the whole
payment order stops and the system requests authorization for the payment item to an external
authorization system. The external system can forward feedback about the authorization to Payment
Engine and the external system can trigger processing of the payment item to be continued.

 Note

The enrichment and validation process in Payment Processing determines the following events:

• Whether an authorization for a payment order is indicated.

• Whether a lock is stored in the associated service level agreement.
• Whether a configurable amount limit has been exceeded, even with existing authorization.

For these events, Exception Control requests payment item authorization. For more information, see
Enrichment and Validation [page 311].

• 18 Trigger return for internal payment item

Payment Engine (FS-PE)

268 PUBLIC Master Data
 The system initiates the return of internal payment items that have been posted to an account
management system. For more information, see Passive Request for Cancellation [page 111].
• 19 Trigger return for external payment item
The system initiates the return of payment items assigned to outgoing payment orders. For more
information, see Active Request for Cancellation [page 108].
• 99 Further processing
The system ignores the error and resubmits the payment item for straight-through processing. For more
information, see End-to-End Payment Processing [page 98].

Integration

You can define response types based on the response category in Customizing. For more information, see
Response Type [page 269].

The following parameters define which response categories are possible for the definition of exception control
rule sets:

• Process
• Object category
• Exception Control phase

One response category can be assigned to more than one combination of these parameters. For more
information, see Exception Control Rule Set [page 272].

13.6.2 Response Type

Definition

A user-definable identification feature to further specify the response of an exception based on the response
category.

Use

The response type controls how the system responds when an error occurs in a payment order, an ordering
party item, a recipient item, or other Payment Engine objects.

You can define response types in Customizing for Payment Engine under Exception Control Define
Response Types .

The system determines a response type for a specific error based on rule sets. For more information, see
Response Type Determination Using Rule Sets [page 275].

Payment Engine (FS-PE)

Master Data PUBLIC 269
Integration

The following characteristics define a response type:

• Clearing area
A response type is valid in a defined clearing area.
For more information, see Clearing Area [page 129].
• Response category
A response type is based on a predefined response category. You can define several response types for the
same response category.
For more information, see Response Category [page 267].
• Priority
When an object is processed and then sent to Exception Control, an error can trigger several different
response types. The priority attached to the various response types determines which response type the
system actually uses.

13.6.3 Correction Rules

If you have set up an exception handling reaction type for manual postprocessing (for a payment order or
payment item), you can set up your system in such a way that it analyzes the manual changes made during this
processing step to see if it can detect recurring correction patterns that could potentially be automated.

If the system finds a correction pattern and this pattern is applied a predefined number of times, a correction
rule is proposed automatically and can be looked up in the Fiori app Manage Correction Rules.

You can also choose to create correction rules manually.

Automatically Generated Correction Rules

All automatically proposed correction rules are based on corrections that have been repeatedly carried out
manually. An algorithm detects the correction pattern. When the correction pattern has been (manually)
applied a predefined number of times, a correction rule is generated.

You can also configure the system to submit orders/items corrected by a correction rule to be submitted to a
release workflow for a certain number of times, before the correction rule becomes fully automatic.

 Example

The system has determined that the error information - 'No bank key or BIC code available' can be
resolved by analyzing the bank address information. Woldwide Bank, Walldorf will be used to determine the
appropriate BIC code WOWIDESXXX. This solution is applied automatically but subsequently the manual
release workflow will be triggered up to 10 times (the threshold defined in Customizing). Starting with the
11th substitution, the release workflow is no longer triggered.

An automatically generated correction rule can have the following initial statuses:

• Inactive

Payment Engine (FS-PE)

270 PUBLIC Master Data
• Incomplete
• Active

Creating a Correction Rule Manually

To create a correction rule manually, carry out the following steps:

1. Open Fiori app Manage Correction Rules.

2. Choose Add.
3. Enter General Criteria such as ID, name, validity, and status.
4. In section Matching Criteria, choose Add to enter the criteria that must be met for the rule to apply
5. In section Change Fields, choose Add to enter the fields you want to change as well as the value you want
them to change to.
6. Save your correction rule.

Assigning an Algorithm

The algorithm used to look for patterns is contained in the application. The sample application AutoPP
is shipped with SAP Payment Engine. It takes into account the Customizing settings specified in Maintain
Automatic Postprocessing (see "Setting up Automatic Rule Correction"):

• How often a pattern needs to occur (Field Threshold) before the system creates a correction rule proposal.
• How often the correction rule has to be manually processed (field Release Threshold) before it can move to
automated correction.

Setting up Automatic Rule Creation

To set your system to analyze corrections and look for patterns that can be turned into correction rules, you
need to carry out the following steps:

1. Assign an application of the category Automatic Post Processing.

1. Set up an Application with the category Automatic Post Processing.
( Payment Engine Basic Settings Local Application Management Systems Define Local
Application Management Systems )
2. Assign it to the relevant clearing area
( Payment Engine Basic Settings Local Application Management Systems Define Local
Application Management Areas )
2. Assign the application to the relevant response type for postprocessing.
( Payment Engine Exception Control Define Response Types Response Types: Payment Order
Define Response Types for Postprocessing , or Payment Engine Exception Control Define Response
Types Response Types: Payment Item Define Response Types for Postprocessing

Payment Engine (FS-PE)

Master Data PUBLIC 271
3. Set up background report /PE1/R_PROCESS_PATTERN (Automatic Postprocessing - Learning New
Solutions) to run at regular intervals for the clearing area in question (for example, every night).

 Note

To run the report immediately, go to SAP Easy Access Payment Engine Periodic Processing
Exception Handling Postprocessing Learn Data-Automatic Postprocessing .

(Transaction /PE1/EH_AUTOPP)

4. Specify the following in Customizing under Payment Engine Exception Control Basic Settings for
Exception Handling Automatic Postprocessing (Learning) Maintain Automatic Postprocessing :
• How often a pattern needs to be detected before a correction rule is created for it.
• How often the correction rule has to be manually processed before it can move to automated
correction.

13.6.4 Exception Control Rule Set

Definition

A framework used to manage a collection of rules for response determination in exception control.

Use

The use and behavior of rule sets for exception control are similar to those of other rule sets that you can define
in Payment Engine, such as rule sets used in Routing Control for business objects (for example, routes and
clearing agreements). For more information, see Rule Set [page 188].

Several Payment Engine components, such as Payment Processing, Routing Control, and Clearing Processing,
are linked to Exception Control. To find a response type, a rule-determination process is performed. For more
information, see Response Type Determination Using Rule Sets [page 275].

If you do not want to differentiate a response-type assignment, you can specify a standard response type.
This standard response type is a general response for a specific combination of process, object category, and
Exception Control phase. For example, you can define a standard response to every error situation along with
one or more deviant rule sets that define different responses for specific payments.

You can manage rule sets for exception control and their rules as follows:

On the SAP Easy Access screen, choose Payment Engine Master Data Exception Control Define
Exception Control (transaction /PE1/EH).

For more information about the procedures, see Managing Exception Control Rules [page 278].

Payment Engine (FS-PE)

272 PUBLIC Master Data
Structure

Exception Control Screen

The screen is divided into the following screen areas:

• Search area
You can enter a text to search for processes, object categories, or Exception Control phases currently
loaded in the navigation tree by means of any text criteria. When you run a search, a new node with the
result is created in the tree.
• Navigation tree
Displays the following levels of nodes in a hierarchical structure:
• Process
Identifies a process category in Payment Engine, which represents the different steps that payment
orders or payment items go through during processing. Payment Engine supports many processes;
however, not all processes are available on the graphical user interface (GUI).
• Object category
Identifies the type of transaction that should be checked. For example, you can classify error checks
for ordering party items or for recipient items.
• Exception Control phase
Specifies the phase in which the error check occurs, for example, enrichment and validation for
payment order or preparations for posting.
Exception Control is divided into different phases. In the navigation tree, you can display the available
combinations of processes, object categories, and Exception Control phases.
• Business object
Displays details about the selected process, object category, and Exception Control phase organized on the
following tab pages:
• Basic Data
Defines a standard response type that is used if a rule set does not contain any rules or if none of the
rule attributes match the error check, payment order attributes, or payment item attributes.
• Executed Checks
Displays the possible error checks. These checks are available as a characteristic of the rule when you
add the rule to a rule set.

 Note

You can enhance the predefined error checks in your customer name space.

• Possible Responses
Displays the possible response categories. These response categories limit the response types
available for selection when you add a rule to the rule set.
• Rules
Displays the rules in a rule set associated with the selected process, object category, and Exception Control
phase.

Payment Engine (FS-PE)

Master Data PUBLIC 273
 Exception Control Screen

Details of Exception Control Rule Set

A rule set consists of one or more rules. One rule refers to exactly one response type. The same response type
can occur in one or more rules.

Each rule consists of a set of characteristics based on the payment order or payment item attributes. These
attributes are rule-set specific. A rule matches if the attributes of a payment order or payment item match the
attributes of the rule.

You can display all available attributes depending on the object category in the rule maintenance. For more
information, see Managing Exception Control Rules.

If the object category of the related rule set is a payment order type, the payment order attributes available
include format, payment order priority, and payment order type. Furthermore, several ordering party item
attributes are available, for example, bank key, amount, and currency.

If the object category of the related rule set is a payment item type, the payment item attributes available
include such as account number, bank country, and payment item type.

The parameters process, object category, and Exception Control phase uniquely determine an exception
control rule set. Exception control rules are uniquely identified by the sequence, which determines the order of
the rules in a rule set. This number is used as the first search criterion during rule determination.

Integration

You can use a release workflow to supervise certain business-related transactions, such as the creation or
change of a standard response type for a defined process, object category, and Exception Control phase or its
related rule set. You can define these specific settings in Customizing for Payment Engine under Exception
Control Exception Handling Release for Exception Handling . For more information, see Release Workflow
[page 419] and Release Object EH (Exception Control Rule Set) [page 280].

Change documents are available when rules or rule sets are changed. You can access change documents by
choosing Extras Change Document .

Payment Engine (FS-PE)

274 PUBLIC Master Data
13.6.4.1 Response Type Determination Using Rule Sets

Use

You can use this function to define business rules related to error responses. Exception Control uses rule sets
to determine a response type that specifies how the system responds to a certain error situation.

To find a response type, a rule-determination process is performed, where each rule is processed sequentially
until the system finds a rule whose conditions are fulfilled completely or until all rules in a rule set have been
analyzed.

Prerequisites

You have defined the necessary settings in Customizing for Payment Engine under Exception Control.

You have defined rule sets for exception control:

On the SAP Easy Access screen, choose Payment Engine Master Data Exception Control Define
Exception Control .

Features

Rule Determination

Several Payment Engine components are linked to Exception Control. Each component performs error checks
on payment orders and payment items in phases. When an error occurs, the component transfers the following
input parameters:

• Process
For example, incoming payment order processing, outgoing payment order processing, or collector
processing.
• Object category
For example, incoming payment order, outgoing payment order, ordering party item, or recipient item.
• Exception Control phase
For example, formal check, enrichment and validation, preparations for posting, or technical error.
• Exception Control check
Specifies which exception for a payment order or payment item triggered Exception Control, such as check
of transaction type locking or invalid bank code number.
• Characteristics of the payment order or payment item
Such as payment order type or payment item type, amount, currency, and bank identifier code (BIC)

Based on these input parameters, Exception Control determines the relevant rule set and then searches for the
appropriate rule. According to the defined sequence in the rule set, Exception Control checks the transferred
values against all rules of the rule set starting with the first rule in the sequence. If this rule does not match, the
next rule is validated. This process is performed until a rule is found in which the values of the payment order or
payment item characteristics match the value range defined in a specific rule.

Payment Engine (FS-PE)

Master Data PUBLIC 275
Each rule has a pointer to a response type created in the clearing area for the executed payment transaction.
In this way, you can use rule sets to implement the business rules that the financial institution has defined. As
soon as the system has found the first matching rule (lowest sequence number), the search is canceled and
the result (response type) is assigned to the payment order or item. Thus, you place detailed rules as first rules
and general rules more at the end of the rule set.

The response type is collected in the error vector of the payment order or payment item and the system
executes the remaining checks in this phase. At the end of the Exception Control phase, Exception Control
analyzes the error vector. The response type with the highest priority is then determined and finally performed.
You can define the response type priority in Customizing.

If no rule matches the error, the standard response type for the defined process, object category, and
Exception Control phase is determined.

Generally, you can use all attributes of the Payment Engine metaformat, that is, payment order and payment
item characteristics, to define the rule sets. In addition, you can use other characteristics to restrict the validity
time of a rule, for example, date or time of day. To determine a more differentiated response type, you can
assign an Exception Control check ID to a rule. This key indicates which error led to a payment item being sent
to exception handling.

Furthermore, you can individually activate and deactivate each rule in a rule set. The system checks only
activated rules. You can reactivate a deactivated rule at any time.

Operators and Checks for Rule Determination

The following operators and checks are available to determine a rule and its corresponding response type:

• Equality operators
Compare a predefined value of an attribute in a rule with the current value of a given payment item or
payment order.
• Interval check
Checks whether the given attribute value lies within the interval that can be defined with the help of “from”
and “to” values.
• Pattern matching
Is based on wildcard characters (“+” for any single character, “*” for any string). You can mix fixed
text components of the rule maintenance with wildcards. Pattern matching is not possible for numerical
information, for example, the transaction amount.
• Comparison operators
Can be determined during rule maintenance. You can use the following comparison operators:
• = Equal to
• ≥ Greater than or equal to
• ≤ Less than or equal to
• > Greater than
• < Less than
• ≠ Not equal to
• List membership check
Is indicated in a rule set when several comparison values can be used within an individual rule.

To speed up the rule-determination process, some index logic is built into the rule set configuration. The index
logic creates indexes for saved rules so that similar rules (sharing the same characteristics) are grouped into
one index entry. If any rule in an index entry does not match the input parameters, the system searches the
next index entry, thus eliminating rules from the search that neither match.

Payment Engine (FS-PE)

276 PUBLIC Master Data
Example

Rule Set

This rule set is defined for the following parameters:

• Process: Incoming payment order processing

• Object category: Incoming payment order
• Exception Control phase: Enrichment and validation of payment order

Sequence Exception Control Payment Order Payment Order Description Re- Further Attributes
Check ID Priority Type Group for sponse Type
Exception Control

1 85 02 ≠ EH_100 Postprocessing of None

payment order

2 85 ≠ 02 ≠ EH_100 Rejection of pay- None

ment order with
correspondence

3 90 Ignore, further None

processing of pay-
ment order or pay-
ment item

Explanation

The system reads these rules as follows:

1. Where a payment order with payment order priority = urgent, payment order type group ≠ bank orders,
and the debit item total does not equal the credit item total, the payment order is transferred to
postprocessing.
2. Where a payment order with payment order priority ≠ urgent, payment order type group ≠ bank
orders, and the debit item total does not equal the credit item total, the payment order is rejected and
correspondence is triggered.
3. Where the percentage of erroneous target items of a payment order exceeds the permitted limit, the error
is ignored and the payment order is further processed.

More Information

Exception Control Rule Set [page 272]

Exception Control (FS-PE-EH) [page 265]

Payment Engine (FS-PE)

Master Data PUBLIC 277
13.6.4.2 Managing Exception Control Rules

Use

You can manage exception control rules as follows:

• Create an exception control rule

• Change an exception control rule
• Delete an exception control rule
• Display an exception control rule

Prerequisites

To create, change, and delete an exception control rule:

• You have defined the response type that you want to assign to the rule with a response category that is
valid for the corresponding process, object category, and Exception Control phase and a unique priority in
Customizing for Payment Engine under Exception Control in the corresponding Customizing activities.
• You have defined the release workflow in Customizing for Payment Engine under Exception Control
Exception Handling Release for Exception Handling .

To display an exception control rule:

You have display rights for the selected clearing area.

Procedure

On the SAP Easy Access screen, choose Payment Engine Master Data Exception Control Define
Exception Control (transaction /PE1/EH) and select a clearing area.

 Note

You can show or hide the rule sets by choosing the Set of Rules pushbutton on the Basic Data tab page.

You can show or hide the search area and navigation tree by choosing the Switch Overview Tree On/Off
pushbutton.

Creating Exception Control Rules

1. From the navigation tree, double-click the corresponding node for the process, object category, and
Exception Control phase in which you want to create an exception control rule.
2. To display the rules screen area, choose the Set of Rules pushbutton on the Basic Data tab page.
For more information about the screen areas on the Exception Control screen, see Exception Control Rule
Set [page 272] under Structure.

Payment Engine (FS-PE)

278 PUBLIC Master Data
3. In change mode, do one of the following:

• Create a new rule by choosing in the rules screen area.

The dynamic selection screen (rule maintenance) appears where you can choose the characteristics
for the rule.

• Copy an existing rule by choosing in the rules screen area.

4. Define the values on the dynamic selection screen and enter an existing response type for the clearing
area.
5. Save the object and trigger the release process by choosing the Release pushbutton.

 Note

You can process only objects with Released status.

Changing Exception Control Rules

1. From the navigation tree, double-click the corresponding node for the process, object category, and
Exception Control phase in which you want to change an exception control rule.
2. To display the rules screen area, choose the Set of Rules pushbutton on the Basic Data tab page.
For more information about the screen areas on the Exception Control screen, see Exception Control Rule
Set under Structure.
3. In change mode, you can change the standard response type in the business object screen area and the
rules in the rules screen area.

4. In the rules screen area, choose the rule that you want to change and choose .
The dynamic selection screen (rule maintenance) appears where you can choose the characteristics for
the rule.
5. Define the values on the dynamic selection screen and enter an existing response type for the clearing
area.
6. You can do one of the following:

• Activate a rule in the rule set by choosing .

• Deactivate a rule in the rule set by choosing .

7. Save the object and trigger the release process by choosing the Release pushbutton.

 Note

You can process only objects with Released status. If the object is not released, the old rule applies.

Deleting Exception Control Rules

1. From the navigation tree, double-click the corresponding node for the process, object category, and
Exception Control phase in which you want to delete an exception control rule.
2. To display the rules screen area, choose the Set of Rules pushbutton on the Basic Data tab page.
For more information about the screen areas on the Exception Control screen, see Exception Control Rule
Set under Structure.

3. In change mode, choose the rule that you want to delete and choose .
The rule is selected for deletion.
4. Save the object and trigger the release process by choosing the Release pushbutton.

Payment Engine (FS-PE)

Master Data PUBLIC 279
  Note

The object is actually deleted when it reaches the Released status.

Displaying Exception Control Rules

1. From the navigation tree, double-click the corresponding node for the process, object category, and
Exception Control phase in which you want to display an exception control rule.
2. To display the rules screen area, choose the Set of Rules pushbutton on the Basic Data tab page.
For more information about the screen areas on the Exception Control screen, see Exception Control Rule
Set under Structure.

3. Choose the rule that you want to display and choose .

The dynamic selection screen (rule maintenance) appears where you can check the details of the rule.

13.6.4.3 Release Object EH (Exception Control Rule Set)

Definition

A release object in Payment Engine used by the system to identify whether the editing of an exception control
rule set by an author or a processor is subject to release.

If the editing of the exception control rule set is subject to release, the system generates a release object EH
(exception control rule set) as a work item that can be processed further by a supervisor or user responsible for
release in the Business Workplace.

Use

Customizing

In Customizing, you can define how many release steps the object must pass (for example, for dual or treble
control) and the conditions when the release workflow is carried out (for example, always, conditional by using
release attributes).

You make the settings for release object EH in Customizing for Payment Engine under Exception Control
Exception Handling Release for Exception Handling in the following Customizing activities:

• Assign Release Procedure to Release Object

• Assign Standard Role to Release Steps
• Assign Workflow and Sub-Workflow to Release Procedure

Channel

Dialog

Individual processing: transaction Define Exception Control (/PE1/EH)

Payment Engine (FS-PE)

280 PUBLIC Master Data
The system checks whether the dialog processing of the exception control rule set is subject to release, and
generates a work item for every release-relevant exception control rule set. If an exception control rule set is no
longer subject to release after processing, the system deletes the associated work item.

Business Application Programming Interface (BAPI)

Like during dialog processing, the system checks whether editing an exception control rule set by using BAPIs
is subject to release and generates a work item for every release-relevant editing. If an exception control rule
set is no longer subject to release after editing, the system deletes the associated work item.

Structure

You can edit release object EH as a work item in the Business Workplace. These methods can affect the status
of the exception control rule set. For more information, see Status and Release Status of Master Data Objects
[page 282].

• Display
Choosing this pushbutton brings you to the dialog transaction Define Exception Control.
• Change
Choosing this pushbutton brings you to the dialog transaction Define Exception Control. The system closes
the old release workflow and triggers a new release process with the changed data. The new release object
status of the exception control rule set is initially For Release. This method in the Business Workplace can
change the status and release status of the exception control rule set as follows:
The system checks the changed item and generates a new work item if applicable and deletes the existing
work item.
• Display change documents
Choosing this pushbutton opens the dialog transaction Define Exception Control with dialog box Display
Change Documents of the exception control rule set.
• Release
This method in the Business Workplace can change the status and release status of the exception control
rule set as follows:
Editing the exception control rule set:

Before Release After Release

Status of the Exception Release Status Status of the Exception Release Status
Control Rule Set Control Rule Set

Inactive For Release Active Released

• Reject
Choosing this pushbutton rejects the change of the exception control rule set.

Payment Engine (FS-PE)

Master Data PUBLIC 281
 This method in the Business Workplace can change the status and release status of the exception control
rule set as follows:
Editing the exception control rule set:

Before Release After Release

Status of the Exception Release Status Status of the Exception Release Status
Control Rule Set Control Rule Set

Inactive For Release Active In Process

More Information

Exception Control Rule Set [page 272]

13.6.4.4 Status and Release Status of Master Data Objects

When you edit the following master data objects in SAP Payment Engine, the status and release status of the
object can change:

• Service level agreement and rule set for service level agreements
• Value date agreement and rule set for value date agreements
• Route and route rule set
• Clearing agreement and clearing agreement rule set
• Customer agreement and customer agreement rule set
• Exception control rule set

Payment Engine (FS-PE)

282 PUBLIC Master Data
The following graphic illustrates the possible statuses for all these objects:

Status and Release Status of a Master Data Object

 Note

To activate the creation or change of an object, always use the release pushbutton even if no release
workflow is set in Customizing for Payment Engine.

Related Information

Release Object SLA (Service Level Agreement) [page 261]

Release Object ROUTE (Route) [page 214]
Release Object CA (Clearing Agreement) [page 227]
Release Object CUSTAGR (Customer Agreement) [page 239]
Release Object CAGRASS (Assignment of General Customer Agreement) [page 241]

Payment Engine (FS-PE)

Master Data PUBLIC 283
Release Object EH (Exception Control Rule Set) [page 280]
Foreign Exchange (FX) [page 284]

13.6.5 Foreign Exchange (FX)

SAP Payment Engine provides a currency translation function (currency exchange).

Features

The currency translation function is based on the identification of a foreign exchange (FX) scenario. It covers
the following steps:

• Enrichment and validation check (E&V check). For more information, see Foreign Exchange Validation in
Recipient Item Checks. [page 322]
• Errors raised by the account management system
• Currency translation options and rule sets in the service level agreement

 Note

If you are using the Foreign Currency Trade Reporting app, the currency translation is performed by the app,
and not by Exception Control.

Activities

Exception Control uses automatic postprocessing systems to support FX broker scenarios. The following class
can be used: /PE1/CL_EH_E_EX_HANDLING.

The class provides the following functions:

1. Determination of the target account currency:

• Comparison between account currency and transaction currency
• Check against customer account data in service level agreements (SLA)
• Call against accounting system to retrieve the account currency
2. Determination of an applicable FX rate:
• After identifying the target account currency, the correct rate type has to be determined based on
Customizing. You can make settings in Customizing for Payment Engine under Payment Item
Determine Foreign Exchange Rate Type .
• Check against the externally provided rate. The SLA determines whether a sender is allowed to provide
rates and if standard rates need to be adjusted.
3. Application of the rate to the item and further processing
4. Update of the bank FX positions by a separate order which will be released for processing upon posting to
the accounting system

Payment Engine (FS-PE)

284 PUBLIC Master Data
Related Information

Foreign Exchange (Overview) [page 122]

Foreign Currency Trade Reporting [page 391]

13.6.6 Processing of Active Returns

Use

You use this process when the system has posted the ordering party item of a payment order, but the recipient
items have to be returned (active return). Payment Engine supports the following scenarios:

• The system has successfully posted the ordering party item and the invalid recipient item has not been
posted.
• The system has successfully posted the ordering party item and the recipient item has also been posted.

 Note

You typically use this process to return payments in the context of the Single Euro Payments Area (SEPA).

Prerequisites

• You have defined a payment order type for active returns in Customizing for Payment Engine under
Payment Order Define Payment Order Types .
• You have defined the transaction type groups used for processing active returns in exception handling in
Customizing for Payment Engine under Payment Items Transaction Types and Transaction Type Groups
Define Transaction Type Groups for Exception Control .
• You have defined a response type for active returns in Customizing for Payment Engine under Exception
Control Define Response Types Response Types: Payment Item Define Response Types for Active
Returns .
• You have defined the settings for active returns, for example, the return reasons and intermediary
accounts, in Customizing for Payment Engine under Exception Control Active Returns .
• You have defined transaction types for active return payment items under Exception Control Active
Returns Maintain Transaction Type for Active Return .

 Note

If this information is missing, the system uses the transaction types defined for active returns under
Payment Items Transaction Types and Transaction Type Groups Maintain and Assign Transaction
Types for Payment Items . If these are not defined, the system uses the offsetting transaction type
defined under Payment Items Transaction Types and Transaction Type Groups Assign Offsetting
Transaction Types to Transaction Types .

Payment Engine (FS-PE)

Master Data PUBLIC 285
• You have mapped the formats required to create incoming messages and outgoing messages in
Customizing for Payment Engine under File Handler SEPA Format Converter : Map PE Internal
Return Reason to Outgoing ISO Code and Map Incoming ISO Code to PE Return Code.

Process

The system has successfully posted the ordering party item and the invalid recipient item has not been posted.

1. The return is initiated in one of the following ways:

• From outside the system over the Create Active Return BAPI (/PE1/BAPI_ACTIVE_RETURN_CREATE).
• As a result of an error using the corresponding exception handling response.
For more information about exception handling, see Exception Control (FS-PE-EH) [page 265].
• Manually using the Create Active Return Order function on the Payment Order and Payment Item
Overview (transaction /PE1/PO_EXPERT).
2. The system validates the recipient item and determines that an active return can be created.

 Note

If the result is that no active return can be triggered, for example, if the recipient item has already been
returned, a final response type is determined.

3. The system reroutes the recipient item to an intermediary account.

4. The system creates:
• A new active return payment order
• An active return ordering party item that reverses the posting of the redirected recipient item
• An active return recipient item that reverses the posting of the original ordering party item (could be an
external customer)

 Note

The new recipient item contains a reference to the original ordering party item and the new ordering
party item references the original recipient item.

5. The system updates the status of the original recipient item to Returned.
6. Depending on the settings defined in Customizing, the system triggers correspondence and sends an
interbank notification and a customer notification to the originator bank.
7. The system submits the created business objects to straight-through-processing.

The system has successfully posted the ordering party item and the recipient item has also been posted.

1. The return is initiated from outside the system over the Create Active Return BAPI (/PE1/
BAPI_ACTIVE_RETURN_CREATE).
2. The system validates the recipient item and determines that an active return can be created.

 Note

If the result is that no active return can be triggered, for example, if the recipient item has already been
returned, a final response type is determined.

Payment Engine (FS-PE)

286 PUBLIC Master Data
3. The system creates:
• A new active return payment order
• An active return ordering party item that reverses the posting of the original recipient item
• An active return recipient item that reverses the posting of the original ordering party item (could be an
external customer)

 Note

The new recipient item contains a reference to the original ordering party item and the new
ordering party item references the original recipient item.

4. The system updates the status of the original recipient item to Returned.
5. Depending on the settings defined in Customizing, the system triggers correspondence and sends an
interbank notification and a customer notification to the originator bank.
6. The system submits the created business objects to straight-through-processing.

Result

The amount in the recipient item is returned to the ordering party of the originator bank.

More Information

End-to-End Payment Processing [page 98]

13.6.7 Full Rejection of Payment Orders

Use

You can use full rejection to reject incorrect payment orders. This can be triggered either by errors in the
payment order detected during enrichment and validation, or by errors in the ordering party items during the
same phase or during posting to the deposits management system. When there is more than one ordering
party item (for example, after an ordering party item split), a payment order rejection triggered by one
incorrect ordering party item still leads to rejection of the full order.

Full order rejection is not possible if, for example, the second ordering party item in a payment order is
incorrect and triggers order rejection, but the first ordering party item has already been posted. In such cases,
partial order rejection might be more suitable.

For more information, see Partial Rejection of Payment Orders [page 288].

Payment Engine (FS-PE)

Master Data PUBLIC 287
Prerequisites

• You have made the required setting in Customizing for Payment Engine (FS-PE), under Exception
Control Define Response Types Response Types: Payment Order Define Response Types for Reversal/
Rejection .
• None of the ordering party or recipient party items has been posted, reserved, or collected.

13.6.8 Partial Rejection of Payment Orders

Use

You can use partial rejection to reject incorrect ordering party payment items of a payment order but continue
to post the remaining payment items of the payment order. You can use this, for example, for payment orders
that have undergone an ordering party item split.

If one of the ordering party items created during splitting triggers a serious error during the enrichment and
validation phase or during posting to the deposits management system, you can reject this payment item and
the corresponding recipient items.

Prerequisites

• You have made the required setting in Customizing for Payment Engine (FS-PE), under Exception
Control Define Response Types Response Types: Payment Order Define Response Types for Reversal/
Rejection .
• None of the corresponding recipient items of the ordering party item has been processed.

Payment Engine (FS-PE)

288 PUBLIC Master Data
14 File Handler (FS-PE-FH)

Use

You use this component to manage the communication between Payment Engine and external feeder systems
and forwarding systems. You can import files that contain payment data from a feeder system, generate
outgoing files that contain the processed data to be sent by a forwarding system, and manage the data to be
stored in the File Handler database (FHDB).

Implementation Considerations

To use the File Handler features, you need to provide the system with information about the files to be imported
from the feeder systems and their formats. Depending on the configuration of the feeder and forwarding
systems, the data is supplied from hard drives, disks, optical devices, or other media. You need to consider the
following aspects:

• Format
The original format of the payment order, such as SWIFT, SEPA, or XML.
• Medium
The physical data storage device that is used to transfer payment transaction files, such as a hard drive or
optical device.
• Channel
The method for the transfer of payment transaction data, such as batch or online transaction.

You define a separate converter ID in Customizing for Payment Engine for each combination of format,
medium, and channel available. You can specify different options for transferring payment transaction data
to and from Payment Engine. If you have defined converter IDs, the system assigns the format, medium, and
channel automatically.

Integration

The File Handler component is connected to external feeder systems and forwarding systems over Business
Application Programming Interfaces (BAPIs) and remote function calls (RFCs). For more information, see
Connection of External Systems [page 153].

All errors that occur in the File Handler (for example errors that result in the creation of a dummy order or
error indicators transferred by a feeder system) are handled by Exception Control. For more information, see
Exception Control (FS-PE-EH) [page 265].

Payment Engine (FS-PE)

File Handler (FS-PE-FH) PUBLIC 289
Features

File Handler accepts inbound messages or payment files from the feeder systems, determines the format,
and transfers the data to the appropriate format converter. The system converts the relevant payment data to
the internal metaformat and passes it to the downstream components for enrichment, validation, and further
processing. It stores all data in the File Handler database, including information that is not relevant to this
process. After the payment data has been processed, it transfers this payment data in the appropriate external
target formats to the forwarding systems.

You can submit payment orders to Payment Engine in batch mode in files. You can also submit single payment
orders to Payment Engine in online mode over a BAPI: the payment order interface, or a service. For more
information on services, see Enterprise Services for Payment Engine [page 155].

File Handler consists of:

• Input Manager (IPM)

The File Handler uploading interface: It receives payment data, such as payment orders, payment items,
and recalls, and creates receipt files for the feeder systems. For more information, see Input Manager
[page 291].
• Output Manager (OPM)
The File Handler downloading interface: It transfers processed payment data in appropriate external target
formats to the forwarding systems, adding data from the FHDB as necessary. For more information, see
Output Manager [page 295].
• File Handler database (FHDB)
The File Handler database: It stores all input data, including the information that is not relevant for
processing, in the original format and makes it available for output. For more information, see File Handler
Database [page 297].

In the Input Manager, the converters map the external payment data formats received from the feeder system
to the internal metaformat. In the Output Manager, the converters convert the processed data from the internal
metaformat into the external target format and transfer it to the forwarding system.

The following standard converter classes are presently available:

• ISO 8583
• ISO 20022
• SWIFT

Furthermore, country-specific and customer-specific converter classes are available, such as:

• CHIPS
• DTAZV
• Eurogiro Envelope
• Fedwire
• SEPA

Payment Engine (FS-PE)

290 PUBLIC File Handler (FS-PE-FH)
14.1 Input Manager

Use

This function receives the incoming payment files and payment transaction messages and converts the data
relevant for payment transactions to the internal metaformat. After conversion, the Input Manager transfers
this data to the relevant components in Payment Engine for processing. The Input Manager can handle
payment and recall data.

The Input Manager stores all incoming data in the File Handler database and merges this data into the
respective outbound messages.

Integration

The Input Manager is integrated in the File Handler component. The external feeder system forwards data to
the Input Manager, which in turn passes data on to the Payment Processing component.. For more information,
see Payment Processing (FS-PE-POP) [page 309]. Payment transaction messages received by Payment Engine
are converted to the internal metaformat for clearing and settlement. For more information, see Routing
Control (FS-PE-RP) [page 205] and Clearing Processing (FS-PE-CP) [page 337].

Prerequisites

• You have made the settings in Customizing for Payment Engine, by choosing File Handler Basic
Settings .
• You have made the settings for external references in Customizing for Payment Engine, by choosing File
Handler Tools .

 Note

External references from the feeder system are used to identify payment orders, payment items,
recalls, and other payment information from an external system.

• You have made the settings for exception handling in Customizing for Payment Engine, by choosing File
Handler File Handler Exception Handling .

Features

Based on the available formats, media, and channels, you specify the converters that are to convert the
payment or recall data into the business objects used. During the file import and the conversion of the data to
the internal metaformat, the Input Manager enriches the business objects created with additional information

Payment Engine (FS-PE)

File Handler (FS-PE-FH) PUBLIC 291
that is needed for processing in Payment Engine. This includes data such as the posting date and system
identification.

Upload of Payment Transaction Data

Various incoming channels are connected to the Input Manager by means of interfaces. The Input Manager
provides a batch interface for low-value or non-time-critical mass payment orders received from the feeder
systems as payment transaction files. The batch interface does not provide any response to the sending
application about the status of the order; it sends only a technical recognition response when the order is
received in Payment Engine. The system processes these files in batch. Batch channels can also be message-
based channels that send asynchronous messages with payment orders. In addition to batch processing, you
can also upload payment transaction data manually.

The Input Manager can also generate recall objects. Using the appropriate converter ID, for example, using the
SWIFT MT192 converter, you can import a recall. For more information about the functions available for recalls,
see Recall Management [page 144].

Conversion of Incoming Payment Transaction Data

For payment processing, the data received is converted into business objects Object List (OL), Payment Order
(PO), Payment Item (PI), and Remittance (RM). For recall processing, the data received is converted into
business object Recall (RE).

All related business objects of a payment order are mutually referenced (OL, PO, PI, and RM).

The system determines whether to process data immediately or later based on the planned processing date
defined in the payment order.

• If no planned processing date is defined, processing takes place immediately.

• If the planned processing date is earlier than or the same as the reconciliation date, processing takes place
immediately.
• If the planned processing date is later than the reconciliation date, the system waits until the dates match
before processing takes place.

Payment Engine supports conversion of the following inbound message types to the internal metaformat:

• CHIPS
• DTAZV
• Eurogiro Envelope
• Fedwire
• ISO 8583
• SEPA
• SWIFT

Activities

• To upload payment data from the feeder systems to Payment Engine, on the SAP Easy Access screen
choose Payment Engine File Handler Import File (Expert) (transaction /PE1/FH_IPM_EXPERT).

Payment Engine (FS-PE)

292 PUBLIC File Handler (FS-PE-FH)
  Note

You can also use transactions /PE1/POLLER and /PE1/PO_EXPERT. For more information, see Import
Data (Expert) [page 293].

• To display data stored in the File Handler database during processing, on the SAP Easy Access
screen choose Payment Engine File Handler Display File Handler Database (transaction /PE1/
FH_SHOW_DB). For more information, see Display File Handler Database [page 298].

More Information

File Handler (FS-PE-FH) [page 289]

Output Manager [page 295]

File Handler Database [page 297]

For more information about the XML converter, see XML Converter [page 300] and SAP Note 1559115.

14.1.1 Import File (Expert)

Use

You use this report to upload payment data from a feeder system to Payment Engine. You import data files
or messages. You can import appropriate files or messages from the application server or from any local
drive including magnetic, optical, or other storage media. The Input Manager converts the input format to the
internal metaformat and maps the relevant payment transaction data to the internal business objects.

 Note

You can import payment data in a file or you can use the asynchronous Process Integration message-based
system provided by SAP NetWeaver.

Prerequisites

• An interface to the required feeder system is available.

• If the data is to be imported from a server, a connection to the server must be open.
• If the data is to be imported using SAP NetWeaver, you have set up the process integration format
converter in Customizing for Payment Engine, by choosing File Handler Process Integration Format
Converter .
• You have made the Customizing settings for the Input Manager. For more information, see Input Manager
[page 291] under Prerequisites.

Payment Engine (FS-PE)

File Handler (FS-PE-FH) PUBLIC 293
Features

Selection

• Converter ID
Identifies the converter to be used and is specified by a combination of format, medium, and channel.
• Format, Medium, and Channel
If you choose a converter ID, these fields are populated automatically.
• File Name
• If the file is stored on the application server, specify a logical file name.
You maintain logical files and logical paths using transaction FILE.
• If the file is stored on a local drive, specify the file path.
The local or server file contains the payment information in text format. To import a local file, you need
to select the appropriate converter and the correct medium in advance.
• Processing Control
• Process (Batch)
• Process (Online)
• Import (Process Automatically)
The system imports the data, converts it, and saves the relevant information in the databases. If you
choose this option, you can process the data in Payment Engine automatically, for example, by using
transaction /PE1/POLLER.
• Import (Process Manually)
The system imports the data, converts it, and saves the relevant information in the databases. If you
choose this option, you must use transaction /PE1/PO_EXPERT for further manual processing. For
more information, see Edit Payment Orders (Expert) [page 373].

Output

In the Input Manager, the converters map the data received from the source system to the Payment Engine
metaformat. The system stores the data in the Payment Engine databases for further processing. At the same
time, the system stores all data in the File Handler database in its original format, regardless of whether this
data is required for further processing of the payment transactions in Payment Engine.

Activities

To access this report, on the SAP Easy Access screen choose Payment Engine File Handler Import File
(Expert) (transaction /PE1/FH_IPM_EXPERT).

 Note

You can also use transactions /PE1/POLLER and /PE1/PO_EXPERT to import data.

Payment Engine (FS-PE)

294 PUBLIC File Handler (FS-PE-FH)
14.2 Output Manager

Use

This function reads the processed payment data and converts the internal metaformat into the external target
format. It also transfers message-based payment transaction data to the relevant outgoing channels.

Integration

The Output Manager is integrated in the File Handler component.The Clearing Processing component forwards
data to the Output Manager, which in turn passes data on to the external forwarding system .

The outbound data is based on the transaction data created during clearing and settlement. For more
information, see Routing Control (FS-PE-RP) [page 205] and Clearing Processing (FS-PE-CP) [page 337].

Prerequisites

• You have made the settings in Customizing for Payment Engine, by choosing File Handler Basic
Settings .
• You have defined the format converters to convert the internal payment order information of the business
objects to an external format based on the available formats, media, and channels of the forwarding
systems. You do this in Customizing for Payment Engine, by choosing File Handler :
• SWIFT Format Converter
• SEPA Format Converter
• Process Integration Format Converter
• You have made the settings for exception handling in Customizing for Payment Engine, by choosing File
Handler File Handler Exception Handling .
• If required, you have made the settings to enrich output payment information, in Customizing for
Payment Engine by choosing File Handler Business Add-Ins (BAdIs) BAdI: Enrichment of Output
Information .
You can enrich the output file generated by the Output Manager with the following:
• Format, medium, and channel
• Payment order type
• Order account number
• Value date of the payment item
• Posting date of the order
• Date of the offset value clearing for banks

Payment Engine (FS-PE)

File Handler (FS-PE-FH) PUBLIC 295
  Note

For separate provisions of cover, this is the processing date of the covering order. Otherwise, it is
the posting date of the clearing item for the order.

• Internal order reference

• Clearing area

Features

Conversion of Outbound Payment Transaction Data

A processed payment transaction to be transferred from Payment Engine is generated and enriched on the
basis of the processed data. The format converters create the specific target format of the outgoing payment
data.

Payment Engine supports the following outbound message types (for conversion from the internal
metaformat):

• CHIPS
• Eurogiro Envelope
• Fedwire
• ISO 8583
• SEPA
• SWIFT (financial and non-financial)

Errors that occur during the outbound conversion are processed in exception handling. The responses depend
on the exception-handling settings you specify in Customizing. An error message is attached to the affected
business object, a payment order, or payment items, and is written to the application log. For more information
about exception handling, see Exception Control (FS-PE-EH) [page 265].

Transfer of Payment Transaction Data to Outgoing Channels

The Output Manager merges the information from the incoming payment data that is stored in the File Handler
database and calls the relevant forwarding system, such as a file manager or middleware. It then transfers
message-based payment orders or payment files to the relevant outgoing channels.

Bulking

You can bulk payment files and request agent outputs such as CAMT messages into one file (with an optional
header), which enables you to restrict the number of files transferred on one day.

 Example

You can bulk files for transfer to the Euro Banking Association (EBA). The corresponding EBA XML formats
are stored in transaction /PE1/XSD for debits and credits.

Payment Engine (FS-PE)

296 PUBLIC File Handler (FS-PE-FH)
Activities

• To execute processing for outgoing payment orders, on the SAP Easy Access screen, choose Payment
Engine Periodic Processing Processes Execute Processes (transaction /PE1/POLLER).
• To display original payment order data that is stored in the File Handler database, on the SAP Easy Access
screen, choose Payment Engine Payment Order Management Edit Payment Orders (Expert)
(transaction /PE1/PO_EXPERT).
• To bulk outgoing payment files, make the required settings in Customizing for Payment Engine (FS-PE),
by choosing File Handler Bulking . Next, choose Periodic Processing Processes Bulk Files for
Outgoing Payments from the SAP Easy Access screen.
You can set up bulking for payment orders on the screen for routes and clearing agreements. From
the SAP Easy Access screen, choose Master Data Routing Control Manage Routes and Clearing
Agreements .

 Note

To set up bulking with request agents on the SAP Easy Access screen, choose Master Data Routing
Control Create Bulk Assignment of Request Agent .

More Information

File Handler (FS-PE-FH) [page 289]

Input Manager [page 291]

File Handler Database [page 297]

For more information about bulking, see the report documentation.

For more information about the bulk assignment of request agents, see Request Agent [page 150] and Entering
Master Data for Bulk Assignment of Request Agent [page 218].

14.3 File Handler Database

Definition

A database for incoming payment data that can contain information not relevant for processing payment
transactions, but that may be of interest to other parties. Entries are created for each type of business object:

• Payment orders
• Payment items
• Recalls

Payment Engine (FS-PE)

File Handler (FS-PE-FH) PUBLIC 297
Use

The Input Manager uses the File Handler database to store all data sent by the feeder system to Payment
Engine, regardless of whether this data is required for further processing of the payment transactions. For more
information, see Input Manager [page 291]. The system does not map data that is not required for processing
to other business objects and does not pass it on to other components.

After the further components of Payment Engine have processed the necessary payment data, the format
converter converts the processed information to the target format. The Output Manager includes the data
stored in the File Handler database in the outgoing payment file. For more information, see Output Manager
[page 295].

The system stores all data in the File Handler database in its original format and includes it after processing
the payment transaction in the outbound data in the target format. You can check the data stored in the File
Handler database at any time. For more information, see Display File Handler Database [page 298].

Example

For data in the Single Euro Payments Area (SEPA) format, the address of an account holder is not required for
internal processing and thus the system does not transfer it to other components. However, the address (along
with all other data) is stored in the File Handler database and is included in the outbound data in the target
format.

14.3.1 Display File Handler Database

Use

You use this report to display payment data sent by a feeder system to Payment Engine that is stored in the File
Handler database. This database stores all original payment data sent by the feeder system including data that
Payment Engine does not require to process payment transactions.

Integration

Payment Engine stores all incoming payment transaction data in the File Handler database in its original
format. After the necessary data has been processed, Payment Engine includes this data in the outbound data
in the target format.

Payment Engine (FS-PE)

298 PUBLIC File Handler (FS-PE-FH)
Prerequisites

You have identified the number and date of creation in Payment Engine of the payment order, payment item, or
recall you want to display.

Features

Selection

• Display mode
• Payment Order Display
• Payment Item Display
• Recall Display
• Clearing area
• Date of payment order, payment item, or recall you want to display
• Number of the payment order, payment item, or recall you want to display
• Data source
• Database
Displays data stored in the File Handler database
• Archive
Displays data that was stored in the File Handler database that the system has archived

 Note

The data in the File Handler database is archived after the residence time has expired. For more
information, see Archiving (FS-PE-ARC) [page 420]

Activities

To access this report, on the SAP Easy Access screen choose Payment Engine File Handler Display File
Handler Database (transaction /PE1/FH_SHOW_DB).

More Information

File Handler Database [page 297]

Payment Engine (FS-PE)

File Handler (FS-PE-FH) PUBLIC 299
14.4 XML Converter Framework

Definition

An object that converts incoming and outgoing XML-based payment files.

Use

XML converters enable the File Handler to convert incoming files from their external XML format into an
internal metaformat used for internal processing of payment orders and payment items and to convert
outgoing orders from the internal metaformat to the required external XML format.

The implementation for a specific format is based on the XML schema. Multiple related schemas can share one
basic converter implementation, which is an implementation of a filter BAdI. The standard system provides,
for example, a converter implementation for the schema PAIN.008.001.02. You can also use this for an
extended XML schema PAIN.008.00x.xx with additional tags. The basis mapping is identical, but the
schema validation differs. In a BAdI for payment orders, you can add further mappings and checks for the
specific formats. The XML format converters derive the XML schema and basic converter implementation.

In the Customizing activity Define Converter Implementation for Format Converter, you can control the XML
schema and converter implementation, alternatively you can do so by using the following BAdIs.

Choose File Handler XML Converter Business Add-Ins (BAdIs) BAdI: Derivation of Message ID for XML
Input Converter and BAdI: Derivation of Message ID for XML Output Converter .

The BAdIs use the filter criteria Converter Package. Each converter package can have its own derivation rules. A
converter implementation is a filter BAdI implementation for the following BAdIs:

• BAdI: Conversion of XML Input for Message Identifier

• BAdI: Conversion of XML Output for Message Identifier

There are individual implementations for XML schemas such as PAIN.008 and PACS.003. The interface
does not specify the business object, which can be a payment order, recall, or any other object type. Default
converter implementations are available for specific formats.

You can either create your own converters for this interface or use special BAdI interfaces for business objects,
which are available in the converter implementations provided in the standard system as follows:

Payment Orders

BAdI: Customer Extensions for PO in Input Converters

Recalls

BAdI: Customer Extensions for Recall in Input Converters

You can use these BAdI interfaces to add more attributes to business objects. XML format converters use the
following logical paths for directory checks:

• Input Manager (IPM)

Payment Engine (FS-PE)

300 PUBLIC File Handler (FS-PE-FH)
 • Logical filename: /PE1/XML_CONVERTER_INPUT_FILE Payment Engine (FS-PE) XML converter input
file (directory)
• Logical path: /PE1/XML_CONVERTER_INPUT_PATH Payment Engine (FS-PE) XML converter input path
• Output Manager (OPM)
• Logical filename: /PE1/XML_CONVERTER_OUTPUT_FILE Payment Engine (FS-PE) XML converter
output file (directory)
• Logical path: /PE1/XML_CONVERTER_OUTPUT_PATH Payment Engine (FS-PE) XML converter output
path
• Stream output classes: /PE1/CL_OPM_OUTPUT_STREAM Payment Engine (FS-PE) to redirect the
conversion output to services or files
• File Output
• FSN (Financial Services Network)

Integration

XML converters are integrated in the File Handler component in Customizing for Payment Engine (FS-PE).

You can assign XML converters with a converter ID. Choose File Handler Basic Settings Maintain
Converter.

More Information

For more information, see SAP Note 1559115 .

14.4.1 ISO 8583 Converter

SAP Payment Engine supports the follwing ISO 8583 message types:

0100 Authorization Request Request from a point-of-sale terminal

for authorization of an amount

0110 Request Response (Outgoing) Request response to a point-of-sale ter-

minal for authorization of an amount

0120 Authorization Advice In case a point-of-sale terminal is dam-

aged or the process times out and the
switch stands in

Payment Engine (FS-PE)

File Handler (FS-PE-FH) PUBLIC 301
0121 Authorization Advice Repeat If the advice times out, this message is
sent again to ensure the execution of
the transaction.

0130 Issuer Response to Authorization Ad- Receipt confirmation of authorization

vice (Outgoing) advice

0200 Acquirer Financial Request Request for funds, typically from an

ATM or pinned point-of-sale device.
Also relevant if the card is not present.

0210 Issuer Response to Financial Request Issuer response to request for funds
(Outgoing)

0220 Acquirer Financial Advice A point-of-sale device is damaged and

the switch stands in, which results in a
force posting in the payment system.
Another scenario is the second mes-
sage of a dual-message system.

0221 Acquirer Financial Advice Repeat If the advice times out, this message is
sent again to ensure the transaction is
executed.

0230 Issuer Response to Financial Advice Receipt confirmation of financial advice

(Outgoing)

0400 Acquirer Reversal Request Reversal of transaction

0420 Acquirer Reversal Advice Advices that a reversal has taken place

0421 Acquirer Reversal Advice Repeat Mes- If the reversal times out
sage

0430 Issuer Reversal Response (Outgoing) Receipt confirmation of reversal advice

14.4.2 SWIFT MT Converter

SAP Payment Engine supports the following financial and non-financial SWIFT message formats:

Financial SWIFT Messages

Message Type Description

101 Request for Transfer

102 Multiple Customer Credit Transfer

102+ Multiple Customer Credit Transfer

Payment Engine (FS-PE)

302 PUBLIC File Handler (FS-PE-FH)
103 Single Customer Credit Transfer

103+ Single Customer Credit Transfer

200 Financial Institution Transfer for Its Own Account

201 Multiple Financial Institution Transfer for Its Own Account

202 General Financial Institution Transfer

202 COV General Financial Institution Transfer

203 Multiple General Financial Institution Transfer

205 Financial Institution Transfer Execution

205 COV Financial Institution Transfer Execution

210 Message to Receive

900 Confirmation of Debit

910 Confirmation of Credit

Non-financial SWIFT Messages

MT MT Name

ACK/NACK Acknowledgement of FIN Message

012 Sender Notification

019 Abort Notification

n90 Advice of Charges, Interest and Other Adjustments

n91 Request for Payment of Charges, Interest and Other Ex-

penses

n92 Request for Cancellation

n95 Queries

n96 Response

n98 Proprietary Message

n99 Free Format Message

 Note

For some of the SWIFT converters there is a UI for non-financial messages. For more information, see
Investigate Non-Financial Messages [page 392].

Payment Engine (FS-PE)

File Handler (FS-PE-FH) PUBLIC 303
14.4.3 SWIFT MX/T2 Converter

SAP Payment Engine supports SWIFT MX converters according to cross-border payments and reporting plus
(CBPR+) as well as SWIFT T2 converters:

 Note

Note that not all business processes are supported, such as agency banking.

SWIFT MX (CBPR+)

Message Type Description

/MX_R23_CAMT.029.001.09 CBPRPlus SR23 Resolution of Investigation

/MX_R23_CAMT.054.001.08 CBPRPlus SR23 Bank To Customer Credit Debit Notification

/MX_R23_CAMT.056.001.08 CBPRPlus SR23 FI To FI Payment Cancellation Request

/MX_R23_MESSAGE_ENVELOPE CBPRPlus SR23 Message Dispatcher

/MX_R23_PACS.002.001.10 CBPRPlus SR23 FI To FI Payment Status Report

/MX_R23_PACS.004.001.09 CBPRPlus SR23 Payment Return

/MX_R23_PACS.008.001.08 CBPRPlus SR23 FI To FI Customer Credit Transfer

/MX_R23_PACS.008.001.08STP CBPRPlus SR23 FI To FI Customer Credit Transfer STP

/MX_R23_PACS.009.001.08 CBPRPlus SR23 Financial Institution Credit Transfer

/MX_R23_PACS.009.001.08ADV CBPRPlus SR23 Financial Institution Credit Transfer ADV

/MX_R23_PACS.009.001.08COV CBPRPlus SR23 Financial Institution Credit Transfer COV

/MX_R23_PACS.010.001.03 CBPRPlus SR23 Interbank Direct Debit

SWIFT T2

Message Type Description

/T2_ADMI.007.001.01 T2 - Receipt Acknowledgement V01

/T2_CAMT.029.001.09 T2 - Resolution of Investigation V09

/T2_CAMT.054.001.08 T2 - Debit/Credit Notification V08

/T2_CAMT.056.001.08 T2 - Payment Cancellation Request V08

/T2_ENV_MSG_SR2020 T2 - Envelope for Business Messages SR2020

/T2_HEAD.001.001.01 T2 - Business Application Header V2.2

Payment Engine (FS-PE)

304 PUBLIC File Handler (FS-PE-FH)
Message Type Description

/T2_PACS.002.001.10 T2 - Payment Status Report V10

/T2_PACS.004.001.09 T2 - Payment Return V09

/T2_PACS008.001.08. T2 - FI to FI Customer Credit Transfer V08

/T2_PACS.009.001.08 T2 - Financial Institution Credit Transfer V08

/T2_PACS.010.001.03 T2 - Financial Institution Direct Debit V03

14.5 Financial Services Network Integration

Use

Payment Engine 8.0 provides the integration to the SAP Financial Services Network (FSN). This means that
Payment Engine is able to receive messages directly from FSN. In addition, it allows sending messages to/via
FSN. The integration consists mainly of two services. One service for inbound and one for outbound direction.

Prerequisites

FSN-specific Customizing is required:

You have defined FSN attributes in Customizing for Payment Engine under:

• File Handler Financial Services Network Integration Assign Converter IDs to FSN Message Type
• File Handler Financial Services Network Integration Assign FSN Message Types to XML Message
Identifiers

14.6 Eurogiro

The Eurogiro standard was developed by Eurogiro, an association of postbanks, banks and money transfer
organisations.

The following Eurogiro formats are processed.

Payment Engine (FS-PE)

File Handler (FS-PE-FH) PUBLIC 305
Format Channel

MT103 Incoming and Outgoing

MT910 Incoming

MT198-93 Incoming and Outgoing

14.7 Notification of Payment Order Processing Status

Use

This function enables the creation of status notifications at certain times during the processing of incoming
payment orders. These notifications can be based on text, for example, a SEPA message or a service such as a
web service call to a system that exposes a web service for obtaining a status update or a combination of a web
service call and a text message.

You can use this function for other channels and formats if required.

Integration

This function is part of payment order processing. To call the report from the SAP Easy Access screen, choose
Periodic Processing Processes Create Status Notification .

Prerequisites

• You have defined a template ID in Customizing for Payment Engine (FS-PE). Choose File Handler
Status Notification Define Notification Templates .
• You have defined status notification rules for the service level agreement by carrying out the following
steps:
1. From the SAP Easy Access menu, choose Master Data Service Level Agreements Manage
Service Level Agreements .
2. Select the service level agreement for which you want to define status notification rules.
3. On the SLA General tab page, choose Correspondence.
4. Go to the Correspondence tab page, choose Set of Rules, then choose Create Rule to create your own
rule definitions.

Payment Engine (FS-PE)

306 PUBLIC File Handler (FS-PE-FH)
Features

When the payment order status changes, and if it has an SLA with an assigned template ID, the system reads
the Customizing settings for the template ID to check whether a notification is to be sent for the new payment
order status. Each time a notification is to be sent, an event handler writes an entry in the notification database
with status New.

If there is no template ID for the SLA, status notification is not created. If an SLA cannot be found for the
payment order, you can still send correspondence, for example, if a payment order was rejected.

On a regular basis, the notification poller reads all payment order entries from the notification database.
Depending on the converter that is assigned to the payment order status in the Customizing settings of the
template ID, the corresponding converter is executed. The system uses this converter to create the outgoing
notification file.

If the notification was created successfully, the system updates the status field in the notification database. If
there were errors, the system updates the database with the error status.

The status notification process is shown below in the graphic.

Status notification process

BAdI Implementation

If required, you can implement the Business Add-In (BAdI) BAdI: Adjustment of Payment Transaction Status
for pain.002. This enables you to adjust the mapping of a business object status in Payment Engine (FS-PE)

Payment Engine (FS-PE)

File Handler (FS-PE-FH) PUBLIC 307
to a status notification status ID, for example, payment order status 173 (Rejected) to ISO status code RJCT.
Payment transaction mapping in Payment Engine (FS-PE) conforms to SEPA regulations.

For more information, see Customizing for Payment Engine (FS-PE) under File Handler Status Notification
Business Add-Ins (BAdIs) BAdI: Adjustment of Payment Transaction Status for pain.002 .

Payment Engine (FS-PE)

308 PUBLIC File Handler (FS-PE-FH)
15 Payment Processing (FS-PE-POP)

Use

You use this component to process payment orders and payment items. You can execute all processes that
need to be performed from the time a payment order is uploaded to Payment Engine and processing is initiated
to the point at which a payment order is transferred to Routing Control.

In Payment Processing, the enrichment and validation process uses a set of checks to verify the completeness
and correctness of information stored about payment orders and payment items and enrich information
as required. The checks performed depend on the Customizing settings and the determined service level
agreement.

Implementation Considerations

You need to define which validation checks are required for each type of payment order and payment item and
the corresponding Customizing settings. For more information, see Enrichment and Validation [page 311].

Integration

The enrichment and validation process is integrated in Payment Processing and can be used only if the system
has been configured. You cannot run the check methods used in enrichment and validation as independent
units of Payment Engine.

Payment Processing is closely linked to the Exception Control component, which handles all errors that occur
during the enrichment and validation process. For more information about error handling, see Exception
Control (FS-PE-EH) [page 265].

If no errors occur in Payment Processing, final processing of a payment takes place in Clearing Processing.
The type of processing depends on the information defined in Routing Control (route, clearing agreement,
customer agreement, value date agreement) and the payment characteristics (payment order and payment
item attributes). For more information, see Routing Control (FS-PE-RP) [page 205] and Clearing Processing
(FS-PE-CP) [page 337].

Features

You can process payment orders and payment items and define payment processing in the following ways:

• Upload and process a package of payment orders for automatic processing

On the SAP Easy Access screen, choose Payment Engine Periodic Processing Processes Execute
Processes (transaction /PE1/POLLER).

Payment Engine (FS-PE)

Payment Processing (FS-PE-POP) PUBLIC 309
• Display an overview of payment orders and payment items and manage payment orders and payment
items
On the SAP Easy Access screen, choose Payment Engine Payment Order Management Edit Payment
Orders (Expert) (transaction /PE1/PO_EXPERT).
For more information, see Edit Payment Orders (Expert) [page 373].

• Manage service level agreements

As part of enrichment and validation, you can manage service level agreements. Service level agreements
provide relevant information about how to process payment orders and payment items.
On the SAP Easy Access screen, choose Payment Engine Master Data Service Level Agreements
Manage Service Level Agreements (transaction /PE1/SLA).
For more information, see Service Level Agreement [page 311] and Managing Service Level Agreements
[page 260].
• Define and perform enrichment and validation checks
You can use the standard checks defined for enrichment and validation or you can define new specific
checks to be performed on the payment orders and payment items.
The enriched information that you can add to the payment items or payment orders is useful for the
enrichment and validation process and for clearing and settlement.
• Reject pending payment orders
If a payment order needs to be rejected, for example, if an enrichment and validation check fails, the
system does not change the status of payment items to Rejected during straight-through processing.
However, you can change the status of all payment items in the payment order. On the SAP Easy Access
screen, choose Payment Engine Periodic Processing Processes Reject Pending Payment Orders
(transaction /PE1/REJECT_PEND_PO).
• Cancel processing of payments
You can create recalls only for payment orders and payment items that have not been finally processed.
For more information, see Recall Management [page 144]. Payment Engine also support the cancellation of
SEPA Direct Debits (SDD). For more information, see Request for Cancellation [page 106].

You can use the following Business Application Programming Interfaces (BAPIs) to perform the same functions
as the Edit Payment Orders (Expert) function.

• /PE1/BAPI_PAYMORDER_GETDETAIL
Retrieves details about a payment order.
The system identifies this instance of the payment order by means of its key and retrieves all instances that
match the search criteria specified in the entry parameters, such as the clearing area, the date, and the
number identifier of the specific payment order.
• /PE1/BAPI_PAYMITEM_GETDETAIL
Retrieves details about a payment item.
The system identifies and retrieves this instance of the payment item by means of its key, which matches
the search criteria specified in the entry parameters, such as the clearing area, the date, and the number
identifier of the specific payment item.

 Note

You can customize these BAPIs to meet special requirements.

For more information about the various Customizing settings and the necessary help structures, see the
SAP Library documentation under Cross-Application Components Business Framework Architecture
(CA-BFA) Enhancements, Modifications... Customer Enhancement and Modification of BAPIs .

Payment Engine (FS-PE)

310 PUBLIC Payment Processing (FS-PE-POP)
15.1 Enrichment and Validation (FS-PE-EV)

Use

This process enables the attributes of payment orders and payment items to be validated in Payment Engine
based on different checks performed when payment processing starts. The system enriches the payment
information as necessary. That is, information is added to the payment orders or payment items based on the
Customizing settings defined for different checks and the determined service level agreement (SLA).

If information is missing or incorrect, Payment Engine can use an internal automatic repair functions to make
the correction, or you can correct information manually depending on the settings defined for exception
handling. For more information, see Exception Control (FS-PE-EH) [page 265]. If an error is so severe that the
internal repair function cannot correct it, Payment Engine can call an external automatic repair function using
an exception handling process.

Payment Engine checks the following for every payment order and payment item it processes in:

• Formal accuracy
For example, account format checks check whether an account is valid for a respective country.
• Referential accuracy
For example, the IBAN check checks whether a payment order has an IBAN and whether the IBAN is
correct.
• Material errors
For example, amount limit checks check whether the amount of a payment transaction is exceeded for a
special payment order type or payment order type group.
• Consistency
For example, the credit and debit check validates whether the amounts assigned to the ordering party
items and the recipient items are consistent.

For more information about the levels of checking performed by Payment Engine, see Enrichment and
Validation Check Set [page 330] and Enrichment and Validation Checking [page 315].

Prerequisites

• You have defined the checks run during enrichment and validation in Customizing for
• Payment Order Payment Order Enrichment and Validation Maintain E&V Checks and
Dependencies
• Payment Order Payment Order Enrichment and Validation Maintain Enrichment and Validation
Check Sets
• Payment Items Payment Item Enrichment and Validation
• Payment Items Transaction Types and Transaction Type Groups
• You have managed service level agreements on the SAP Easy Access screen by choosing
Payment Engine Master Data Service Level Agreements Manage Service Level Agreement
(transaction /PE1/SLA). For more information, see Service Level Agreement [page 256] and Managing
Service Level Agreements [page 260].

Payment Engine (FS-PE)

Payment Processing (FS-PE-POP) PUBLIC 311
Process

1. The system reads the payment orders that are pending processing in Payment Engine.
2. The system determines the service level agreement (SLA) based on the default bank code number and the
account number in the ordering party item of the payment order.
3. The system enriches the payment order with the required information for the clearing area SLA and
performs the necessary formal and material checks.
4. The system checks whether a corresponding customer SLA or customer segment SLA exists.
If a match is found, the system:
1. Performs the necessary formal and material checks that are defined in the customer SLA or customer
segment SLA.
2. Enriches the payment order or payment item with the required information.
5. The system determines the processing program.
In Customizing, you can define which checks the system runs based on the payment order type and the
transaction types of the individual payment items.
6. The system performs validation checks.

 Note

The results of the validation checks are listed in the logs of the corresponding business objects:

• The results of payment order checks and cross-item checks are listed in the log of the payment
order.
• The results of checks on ordering party items and recipient items are listed in the corresponding
payment item logs.

7. The system transfers the ordering party items of successfully validated payment orders to Routing Control,
provided that the execution date of a payment order is not in the future.

More Information

Payment Processing (FS-PE-POP) [page 309]

Exception Control (FS-PE-EH) [page 265]

Routing Control (FS-PE-RP) [page 205]

15.1.1 Check Processing Date

Use

This function is integrated in the enrichment and validation process and determines an appropriate processing
mode for payment orders and payment items based on the planned processing date.

Payment Engine (FS-PE)

312 PUBLIC Payment Processing (FS-PE-POP)
The system determines one of the following processing modes:

• E- Execution mode
Determined if the Payment Engine reconciliation settlement date is the same as the planned processing
date of the payment order and the submission date is earlier than the planned processing date.
• S- Submission mode
Determined if the planned processing date is later than the reconciliation settlement date and the
submission date is earlier than the planned processing date.
This mode is used for payment orders with a planned processing date in the future. When this mode is
determined, the payment order retains status 117 (E & V completed) until its planned processing date is
reached.
• X- Execution/ Submission mode
Determined if the planned processing date of the payment order is the same as the reconciliation
settlement date or if the planned processing date is earlier than the reconciliation settlement date.

More Information

Enrichment and Validation [page 311]

15.1.2 Enrichment and Validation Check

Definition

A checking procedure performed as part of the enrichment and validation process, which validates the
attributes of payment orders and payment items and adds additional information that is needed for further
processing of payment orders and payment items based on the settings defined for different checks.

Use

You use different types of enrichment and validation checks to validate and enrich the information of a
payment order and its payment items and payment items in different payment orders (cross-item checks).
You use the standard checks defined in Payment Engine or you create your own enrichment and validation
checks to meet your requirements. You can also use standard checks and customized checks together. For
more information about the check methods, see Enrichment and Validation Checking [page 315].

You can define your own checks in Customizing for Payment Engine under Payment Order Payment Order
Enrichment and Validation Maintain E&V Checks and Dependencies .

 Caution

Do not change the structure of enrichment and validation checks. Use the same structure as the structure
defined for the standard checks of payment orders and payment items.

Payment Engine (FS-PE)

Payment Processing (FS-PE-POP) PUBLIC 313
Structure

All enrichment and validation checks must have the same structure. You must configure new checks in
accordance with the following structure:

• Check ID
Identifies a customized enrichment and validation check.
• Check type
Specifies what the system is to check (payment order, payment item, or cross-item checking).
• Error ID
Defines the error handling category for Exception Control.
• Routine class
Specifies the routine class that contains the check method to be performed.
• Routine method
Specifies the method that performs the enrichment and validation check (the check itself).
• Check status
Enables or disables an enrichment and validation check for Exception Control.
• Accumulation class
Specifies the routine class that contains the check method to be performed for cross-item checking.
• Accumulation method
Specifies the method that performs the enrichment and validation accumulation check, which stores the
values used by cross-item checks.

Integration

In Payment Processing, the system checks that the information in payment orders and payment items is
correct and complete. If information is incorrect or missing, Payment Engine sends all errors detected during
enrichment and validation to Exception Control for exception handling. Depending on the severity of the errors
and the response types determined for each error, processing of the payment order continues or stops. For
more information, see Exception Control (FS-PE-EH) [page 265].

When you have created a new check with a unique check ID and configured it for the enrichment and validation
process, you can assign this check to an enrichment and validation check set. Based on the Customizing
settings, the system retrieves the check sets during enrichment and validation and performs all customized
checks on payment orders and payment items.

You can group enrichment and validation checks in check sets, in Customizing for Payment Engine, choose
Payment Order Payment Order Enrichment and Validation Maintain Enrichment and Validation Check
Sets .

Furthermore, you can configure the mandatory sequence in which you want the system to perform certain
enrichment and validation check methods. To do this, in Customizing for Payment Engine, choose Payment
Order Payment Order Enrichment and Validation Maintain Enrichment and Validation Check Sets .

Payment Engine (FS-PE)

314 PUBLIC Payment Processing (FS-PE-POP)
More Information

Enrichment and Validation Check Set [page 330]

15.1.2.1 Enrichment and Validation Checking

Use

This function validates payment orders and payment items in Payment Engine during the enrichment and
validation process.

Prerequisites

• You have defined a check set and assigned a rule type in Customizing for Payment Engine under
Payment Order Payment Order Enrichment and Validation Maintain Enrichment and Validation Check
Sets .
• You have defined dependencies for the checks, for example, the customer segment check has to be
run before the SLA check, in Customizing for Payment Engine under Payment Order Payment Order
Enrichment and Validation Maintain E&V Checks and Dependencies .
• You have assigned the enrichment and validation checks to a check set in a specific sequence under
Payment Order Payment Order Enrichment and Validation Maintain Enrichment and Validation Check
Sets Assign Checks to Enrichment & Validation Check Sets .

 Note

You also define the severity of an error in the activity Assign Checks to Enrichment & Validation Check
Sets.

Features

You can determine a group of enrichment and validation checks for each payment order and payment item
in enrichment and validation check sets. The system performs the checks during payment processing in
a specified sequence and a specific processing mode. It determines an appropriate processing mode for
payment orders and payment items based on the planned processing date. For more information, see Check
Processing Date [page 312].

The system performs validation checks at different levels. For more information, see:

• Payment Order Checks [page 316]

• Ordering Party Item Checks [page 319]

Payment Engine (FS-PE)

Payment Processing (FS-PE-POP) PUBLIC 315
• Recipient Item Checks [page 322]
• Cross Item Checks [page 327]

 Note

The system performs cross item checks after the payment order check and payment item checks. It uses
the same attributes for cross item checking as the attributes that you define for payment order checks.

Every check can detect normal and severe errors. If a check detects an error, the system logs the error, the
enrichment and validation process continues, and the system runs all checks on all business objects. If a check
detects a severe error, the severity indicator is additionally set.

More Information

Enrichment and Validation [page 311]

Enrichment and Validation Check [page 313]

Enrichment and Validation Check Set [page 330]

15.1.2.1.1 Payment Order Checks

Use

You use these enrichment and validation checks to validate payment orders in Payment Engine during the
enrichment and validation process.

Prerequisites

• You have defined the general Customizing settings for enrichment and validation. For more information,
see Enrichment and Validation Checking [page 315] under Prerequisites.
• You have defined a payment order type group for enrichment and validation in Customizing for Payment
Engine under Payment Order Payment Order Enrichment and Validation Maintain Enrichment and
Validation Check Sets Maintain Payment Order Type Group for E&V .
• You have assigned a new payment order type group to the payment order type Standard Payment Order
(Incoming) in Customizing for Payment Engine under Payment Order Define Payment Order Types .
• You have assigned the payment order type groups for enrichment and validation to an enrichment
and validation check set in Customizing for Payment Engine under Payment Order Payment Order
Enrichment and Validation Maintain Enrichment and Validation Check Sets .

Payment Engine (FS-PE)

316 PUBLIC Payment Processing (FS-PE-POP)
Features

The following table describes the payment order checks supported by Payment Engine.

Payment Order Checks

Check Method Description

Enrichment Ordering Customer SLA Enriches a payment order with the SLA based on the ac-
count information of the ordering party item.
(CHECK_E_SLA)

Segment Enrichment Enriches the ordering party item with the customer ID and
the segment ID and the payment order with the segment ID.
(CHECK_E_SEGMENT)

Check Authority Flag Checks whether:

(CHECK_V_CUST_AUTH_FLG) • A payment order is authorized by an external system.

• A lock is set in the corresponding service level agree-
ment (SLA).
• The amount defined in Customizing is exceeded.

You can define upper and lower limits for amounts sent
in payment orders in Customizing for Payment Engine un-

der Payment Order Payment Order Enrichment and

Validation Check Specific Configuration Maintain Order

Limits for Payment Order Authorization .

Check Submission Agreement Exists Checks whether the ordering party is authorized to submit
payment orders with a specific combination of format, chan-
(CHECK_V_ORD_TYPE_FORMAT)
nel, and payment order type group as defined in the SLA.

Validate Mass Credit/Direct Debit/Bank Checks whether the defined payment order type is valid for
the clearing area.
(CHECK_V_TYPE)

Format/Medium/Channel Validation Checks that the combination of format, medium, and chan-
nel is valid against the SLA. Furthermore, the format, me-
(CHECK_V_FORMAT_MEDIUM_CHANNEL)
dium, and channel are checked for validity independently
according to the setting defined in Customizing for Payment

Engine under File Handler Basic Settings .

Payment Order Priority Checks whether the priority is valid for the clearing area.

(CHECK_V_PRIORITY)

Determine Client/Customer-Specific Prioritization Gives another prioritization if a higher priority is defined in

the SLA than in the payment order.
(CHECK_E_PRIORITY)

Payment Engine (FS-PE)

Payment Processing (FS-PE-POP) PUBLIC 317
Check Method Description

Bank Key/ BIC Validation Checks whether the bank code and the BIC of the external
sender are valid (in PE1/T_BLZ and /PE1/T_BIC).
(CHECK_V_BLZ_BIC)
Determines whether a combination of bank code and BIC
are valid according to the setting defined in Customizing for

Payment Engine under Payment Order Payment Order

Enrichment and Validation Check Specific Configuration

Maintain Internal Bank Code Number/BIC Inventory .

Calculate Planned Processing Time Checks whether a payment order is delivered within the
timeframe defined in the SLA. This check is only performed
(CHECK_V_CUT_OFF_TIME)
if the planned processing date is equal to the functional sub-
mission date and the current reconciliation date.

Planned Processing Time Enrichment Determines and enriches the planned processing time for a
payment order.
(CHECK_E_PROC_TIME)

Check FH Error Flag Checks whether an error was detected in the payment order
in File Handling.
(CHECK_V_FH_FORMAT_ERROR)

Recall Check Checks whether a recall exists for a payment order.

(CHECK_V_PO_RECALL)

Bank File Clearing Data Determines the clearing account of an ordering party item
of incoming payment orders by using the data defined
(CHECK_E_BNKCLEAR)
for the bank file clearing account. To access this data, on

the SAP Easy Access screen, choose Payment Engine

Master Data Bank File Clearing Manage Bank File

Clearing Accounts (transaction /PE1/MN_BFC_N).

Business Partner Clearing Account Determines the clearing account of an ordering party item of
incoming payment orders by using the account information
CHECK_E_BANK_BP_ACCOUNT
on a business partner.

Batch Booking Validation(CHECK_E_BATCH_BOOKING) Checks whether a customer is allowed to submit the Batch
Booking Indicator using its Service Level Agreement. It en-
riches the indicator at the order object.

Check Requirement of Cover Funds Checks whether cover funds are required.

CHECK_E_COVER_FUNDS_REQUIRED

Check for Duplicate Orders Checks for duplicate orders. The check is contained in class
PE1/CL_PO_EV_DUPLICATE_PO2.
CHECK_ORDER

Payment Engine (FS-PE)

318 PUBLIC Payment Processing (FS-PE-POP)
Check Method Description

Mandatory Fields Check Checks whether mandatory fields are filled in.

CHECK_V_MUST_FIELDS_PO

More Information

Ordering Party Item Checks [page 319]

Recipient Item Checks [page 322]

Cross Item Checks [page 327]

15.1.2.1.2 Ordering Party Item Checks

Use

You use these checks to validate ordering party items in Payment Engine during the enrichment and validation
process.

Prerequisites

• You have defined the general Customizing settings for enrichment and validation. For more information,
see Enrichment and Validation Checking [page 315] under Prerequisites.
• You have maintained the transaction type groups for enrichment and validation in Customizing
for Payment Engine under Payment Order Payment Order Enrichment and Validation Maintain
Enrichment and Validation Check Sets Maintain Transaction Type Groups for E&V .
• You have assigned transaction types for payment items to a transaction type group for enrichment and
validation in Customizing for Payment Engine under Payment Items Transaction Types and Transaction
Type Groups Define Transaction Types .
• You have assigned the transaction type groups for enrichment and validation to an enrichment and
validation check set in Customizing for Payment Engine under Payment Order Payment Order
Enrichment and Validation Maintain Enrichment and Validation Check Sets Assign E&V Check Set for
Payment Item .

Payment Engine (FS-PE)

Payment Processing (FS-PE-POP) PUBLIC 319
Features

The following table describes the ordering party item checks supported by Payment Engine.

Payment Item Checks — Ordering Party Items

Check Method Description

Check Transaction Type Locking Check Checks whether the transaction type (group) is locked in the
determined SLA.
(CHECK_V_TRANSXN_TYPE)

Check Transaction Type Checks whether the transaction type is valid in accordance
with the setting defined in Customizing for Payment Engine
(CHECK_V_TRANS_TYPE)
under Payment Item Transaction Types and Transaction

Type Groups Define Transaction Types .

Maximum Amount per Transaction Type Checks the transaction type of the payment item against
a limit defined in Customizing for Payment Engine under
(CHECK_V_MAX_AMOUNT_X_TYPE)
Payment Item Transaction Types and Transaction Type

Groups Define Transaction Types .

Check Payment Item Priority Assigns the highest priority of either the payment item or
the value defined in the SLA.
(CHECK_V_PI_PRIORITY)

Determine Client/Customer-Specific Prioritization Assigns the highest priority from either the payment item or
the value defined in the SLA.
(CHECK_E_PRIORITY)

Customer-Specific Payment Item Amount Limit Check Validates the transaction amount of the ordering party item
against a limit customized in the SLA for each transaction
(CHECK_V_AMOUNT_LIMIT)
type.

Calculation of Posting Date Determines the posting date for an ordering party item
based on the due date.
(CHECK_E_POSTING_DATE)

Feedback Date Calculation Determines the latest feedback date required from the ac-
count management system to start processing on time and
(CHECK_E_LATEST_FBACK_DATE)
meet the due date: latest feedback date = due date – mini-
mum offset (the settlement date or the due date for submis-
sion of a payment transaction).

You define the minimum offset in Customizing for Payment

Engine under Exception Control SEPA .

Transaction Currency/Amount Validates fields TR_AMOUNT and TR_CURR.

(CHECK_V_TR_AMOUNT)

Payment Engine (FS-PE)

320 PUBLIC Payment Processing (FS-PE-POP)
Check Method Description

Account Currency/Amount Validates fields A_AMOUNT and A_CURR.

(CHECK_V_A_AMOUNT)

Check Account Substitution Substitutes the account information based on a defined

account substitution rule (rules can be created using a
(CHECK_E_ACC_SUBSTITUTION)
BAPI in the standard system or by using transaction /PE1/
MN_ACCSUBS).

For more information, see Account Substitution [page 185].

Account Number Checksum Validates the checksum of the account number against
defined checksum methods that you can define in Cus-
(CHECK_E_ACC_NR_CHECKSUM)
tomizing for Payment Engine under Payment Order

Payment Order Enrichment and Validation Check Specific

Configuration Maintain Checksum Methods .

Account Details Validates account information.

(CHECK_V_ACCOUNT)

Bank Key/BIC Validation Checks for a valid bank code and BIC in /PE1/T_BLZ
and /PE1/T_BIC.
(CHECK_V_BLZ_BIC)
The method checks the following attributes:

• Bank key
• BIC code (SWIFT address)
• Bank key reference account
• BIC reference account

IBAN Validation Checks the structure and validity of the IBAN.

(CHECK_V_IBAN) Extracts the bank country, bank key, and account number.

BBAN/IBAN Validation Validates the following fields:

(CHECK_V_BBAN_IBAN) COUNTRY, BANKKEY, ACCT_NO, IBAN and

REF_COUNTRY, REF_BANKKEY, REF_ACCT_NO,
REF_IBAN

IBAN/BIC Validation Validates the following fields:

(CHECK_V_IBAN_BIC) IBAN, BIC and REF_IBAN, REF_BIC

Derive IBAN from BBAN Derives the IBAN from the BBAN.

(CHECK_E_BBAN_IBAN) It is also possible to enable third-party determination of

account data based on the IBAN by using BAdI /PE1/
BADI_BIC_UTILITIES.

Payment Engine (FS-PE)

Payment Processing (FS-PE-POP) PUBLIC 321
Check Method Description

Derive BIC from IBAN Derives the BIC from the IBAN. It is also possible to enable
third-party determination of the BIC based on the IBAN by
(CHECK_E_IBAN_BIC)
using BAdI /PE1/BADI_BIC_UTILITIES.

ISO Code Validation Validates the ISO code in accordance with ISO-3166.

(CHECK_V_ISO)

Check of Blank Checks Validates the number of blank checks against manually
maintained check numbers in Payment Engine.
(CHECK_V_BLANK_CHEQUE)

Embargo Check: PI is Embargo Relevant For information, see Embargo Check [page 333].

(CHECK_V_EMBARGO)

Check FH Error PI Checks whether an error was detected in the payment item
in the File Handler.
(CHECK_V_FH_FORMAT_ERROR)

Crisis Check Checks whether the payment item is affected by a crisis

situation.
CHECK_V_CRISIS

Mandatory Fields Check Checks whether mandatory fields are filled in.

CHECK_V_MUST_FIELDS_PI

More Information

Payment Order Checks [page 316]

Recipient Item Checks [page 322]

Cross Item Checks [page 327]

15.1.2.1.3 Recipient Item Checks

Use

You use these enrichment and validation checks to validate recipient items in Payment Engine during the
enrichment and validation process.

Payment Engine (FS-PE)

322 PUBLIC Payment Processing (FS-PE-POP)
Prerequisites

• You have defined the general Customizing settings for enrichment and validation. For more information,
see Enrichment and Validation Checking [page 315] under Prerequisites.
• You have maintained the transaction type groups for enrichment and validation in Customizing
for Payment Engine under Payment Order Payment Order Enrichment and Validation Maintain
Enrichment and Validation Check Sets Maintain Transaction Type Groups for E&V .
• You have assigned transaction types for payment items to a transaction type group for enrichment and
validation in Customizing for Payment Engine under Payment Items Transaction Types and Transaction
Type Groups Define Transaction Types .
• You have assigned the transaction type groups for enrichment and validation to an enrichment and
validation check set in Customizing for Payment Engine under Payment Order Payment Order
Enrichment and Validation Maintain Enrichment and Validation Check Sets Assign E&V Check Set for
Payment Item .

Features

The following table describes the recipient item checks supported by Payment Engine.

Payment Item Checks — Recipient Items

Check Method Description

Transaction Type Validity Check Validates the transaction type against the settings defined

(CHECK_V_TRANS_TYPE) in Customizing for Payment Engine under Payment Item

Transaction Types and Transaction Type Groups Define

Transaction Types .

Check Transaction Type Locking Check Checks whether the transaction type or transaction type
group of the payment item is locked for the item in the SLA.
(CHECK_V_TTYPE_LOCK)

Payment

Maximum Amount per Transaction Type Checks the transaction of the item against a limit defined

(CHECK_V_MAX_AMOUNT_X_TYPE) in Customizing for Payment Engine under Payment Item

Transaction Types and Transaction Type Groups Define

Transaction Types .

Segment Enrichment Enriches the payment item with the segment the customer
belongs to.
(CHECK_E_SEGMENT)

Determine Client/Customer-Specific Prioritization Assigns the highest priority from either the payment item or
the value defined in the SLA.
(CHECK_E_PRIORITY)

Payment Engine (FS-PE)

Payment Processing (FS-PE-POP) PUBLIC 323
Check Method Description

Check Payment Item Priority Assigns the highest priority of either the payment item or
the value defined in the SLA.
(CHECK_V_PI_PRIORITY)

Customer-Specific Payment Item Amount Limit Check Checks the amount against an amount limit for the payment
order type group or payment order type defined in the SLA.
(CHECK_V_AMOUNT_LIMIT)

Country Restriction Checks whether the SLAs assigned to the payment order
contain a restriction for the bank country and the transac-
(CHECK_V_CNTRY_RESTRICTION)
tion category of the recipient item.

Calculation of Posting Date Determines the posting date for the recipient item based on
the due date.
(CHECK_E_POSTING_DATE)

SEPA Timestamp Too Late Checks whether the latest possible submission date of a
SEPA transaction for a given due date is violated according
(CHECK_V_DUE_DATE_LATE)
to the settings defined in Customizing for Payment Engine

under SEPA Maintain SEPA Timeframe Validation .

SEPA Timestamp Too Early Checks whether the earliest possible submission date of a
SEPA transaction for a given due date is violated according
(CHECK_V_DUE_DATE_EARLY)
to the settings defined in Customizing for Payment Engine

under SEPA Maintain SEPA Timeframe Validation .

Timeframe Validation of SEPA R-Transactions Checks whether an R-transaction is submitted within a time-
frame defined in Customizing for Payment Engine under
(CHECK_V_AR_TIMEFRAME)
SEPA Maintain SEPA Timeframe Validation .

Check Recall Payment Item Checks whether a recall exists for the recipient item.

(CHECK_V_PI_RECALL)

Send-Back Validation Checks whether the original item was already subject of an
R-transaction.
(CHECK_V_AR_ITEM)

SEPA Check for Bank Country Checks the bank country field of incoming payment items
against the countries defined in Customizing Payment
(CHECK_V_SEPA_COUNTRY)
Engine under SEPA Maintain SEPA Country Check
where you define countries that are members of the Single
European Payments Area (SEPA).

Transaction Currency/Amount Validates fields TR_AMOUNT and TR_CURR.

(CHECK_V_TR_AMOUNT)

Account Currency/Amount Validates fields A_AMOUNT and A_CURR.

(CHECK_V_A_AMOUNT)

Payment Engine (FS-PE)

324 PUBLIC Payment Processing (FS-PE-POP)
Check Method Description

Account Number Checksum Validation Validates the checksum of the account number against de-
fined checksum methods.
(CHECK_E_ACC_NR_CHECKSUM)
You can define the checksum methods in Customizing for

Payment Engine under Payment Order Payment Order

Enrichment and Validation Check Specific Configuration

Maintain Checksum Methods .

Customer-Specific Account Substitution Substitutes the account information based on a defined

account substitution rule (rules can be created using a
(CHECK_E_ACC_SUBSTITUTION)
BAPI in the standard system or by using transaction /PE1/
MN_ACCSUBS).

For more information, see Account Substitution [page 185].

Account Details Validates the account information.

(CHECK_V_ACCOUNT)

BBAN/IBAN Validation Validates the following fields:

(CHECK_V_BBAN_IBAN) COUNTRY, BANKKEY, ACCT_NO, IBAN and

REF_COUNTRY, REF_BANKKEY, REF_ACCT_NO,
REF_IBAN

IBAN Validation Validates the structure and checksum of the IBAN.

(CHECK_V_IBAN) Extracts the bank country, bank key, and account number.

Bank Key/BIC Validation Checks for a valid bank key and BIC in /PE1/T_BLZ
and /PE1/T_BIC.
(CHECK_V_BLZ_BIC)
The method checks the following attributes:

• Bank key
• BIC code (SWIFT address)
• Bank key reference account
• BIC reference account

IBAN/BIC Validation Validates the following fields:

(CHECK_V_IBAN_BIC) IBAN, BIC and REF_IBAN, REF_BIC.

Derive BIC from IBAN Derives the BIC from the IBAN.

(CHECK_E_IBAN_BIC) It is also possible to enable third-party determination

of the BIC based on the IBAN by using BAdI /PE1/
BADI_BIC_UTILITIES.

Payment Engine (FS-PE)

Payment Processing (FS-PE-POP) PUBLIC 325
Check Method Description

Derive IBAN from BBAN Derives the IBAN from the BBAN.

(CHECK_E_BBAN_IBAN) It is also possible to enable third-party determination of

account data based on the IBAN by using BAdI /PE1/
BADI_BIC_UTILITIES.

Clearing System Enrichment Enriches the clearing system based on the routing directory.

(CHECK_E_CLEARING_SYSTEM)

Foreign Country Enrichment Enriches the foreign country mark from the order.

(CHECK_E_FOREIGN_MARK)

ISO Code Validation Validates the ISO code.

(CHECK_V_ISO)

Embargo Check For information, see Embargo Check [page 333].

(CHECK_V_EMBARGO)

Check FH Error PI Checks whether an error was detected in the payment item
in the File Handler.
(CHECK_V_FH_FORMAT_ERROR)

Check for FX scenario Checks for FX scenario

(CHECK_V_FX_SCENARIO)

Transaction Chain Validation Checks the ordering BIC, the beneficiary BIC, and the
transaction currency to determine the payment transaction
(Cross border)
chain.

Transaction Charge Validation Validates the charges provided by a sender bank in a BEN
scenario based on the:
(CHECK_V_TRANS_CHARGES)
• Charge condition group
• Bank identifier code (BIC)
• Charge category
• Transaction currency
• Transaction amount
• Validity date

Enrich the account currency based on internal data Enriches the account currency based on internal data

(CHECK_E_ACCOUNT_CURRENCY)

Payment Item Check Operation Operates the Payment Item Check

(CHECK_V_CUSTOM_RATE_SUBMISSION)

Payment Engine (FS-PE)

326 PUBLIC Payment Processing (FS-PE-POP)
Check Method Description

Crisis Check Checks whether the payment item is affected by a crisis

situation.
CHECK_V_CRISIS

Mandatory Fields Check Checks whether mandatory fields are filled in.

CHECK_V_MUST_FIELDS_PI

More Information

Payment Order Checks [page 316]

Ordering Party Item Checks [page 319]

Cross Item Checks [page 327]

15.1.2.1.4 Cross Item Checks

Use

You use these enrichment and validation checks to cross-validate all payment item types including payment
items in different payment orders.

 Note

The system performs cross item checks after the payment order check and payment item checks. It uses
the same attributes for cross item checking as the attributes that are defined for payment order checks.

Prerequisites

• You have defined the general Customizing settings for enrichment and validation. For more information,
see Enrichment and Validation Checking [page 315] under Prerequisites.
• You have defined the Customizing settings for enrichment and validation of payment orders. For more
information, see Payment Order Checks [page 316] under Prerequisites.
• You have defined the Customizing settings for enrichment and validation of payment items. For more
information, see Ordering Party Item Checks [page 319] or Recipient Item Checks [page 322] under
Prerequisites.

Payment Engine (FS-PE)

Payment Processing (FS-PE-POP) PUBLIC 327
Features

The following table describes the cross item checks supported by Payment Engine.

Cross Item Checks

Check Method Description

Ordering Party Item Split Splits the ordering party item based on the attributes of the
recipient item, such as transaction type group, reference ac-
(CHECK_E_ORP_SPLIT)
count connection, internal/external flag, or SAP client flag.

You can customize the transaction types for splitting or-

dering party items in Customizing for Payment Engine

under Payment Order Payment Order Enrichment

and Validation Check Specific Configuration Maintain

Transaction Type for ORP Item Split .

Determine Client/Customer-Specific Amount Limit Check Checks whether the amount of the payment items is ex-
ceeded for a special payment order type/payment order
(CHECK_V_ITEMS_AMOUNT_LIMIT)
type group in the determined SLA.

Duplicate Check Payment Order Checks for duplicate processing of a payment order by cal-
culating a checksum.
(CHECK_ORDER)
In the SLA, you can define whether the duplicate check is
executed, not executed, or ignored.

Credit/Debit Check Compares the amount of the ordering party item and recipi-
ent items and sets an error if there is an imbalance.
(CHECK_V_DEBIT_CREDIT)

Error Rate Check Recipient Items Calculates the error rate of fatal and all errors of recipient
items and generates an error if the error rate defined for a
(CHECK_V_NUM_INCORRECT_RCPITEMS)
specific payment order type (payment order type group) in
the SLA is exceeded.

You can activate or deactivate the error percentage calcula-

tion in Customizing for Payment Engine under Payment

Order Payment Order Enrichment and Validation Check

Specific Configuration Error Rate Check Maintain

Customer-Specific Recipient Party Item Error Check .

Transaction Charge Enrichment Enriches the ordering party item with the payment transac-
tion charges determined for the recipient item.
(CHECK_E_TRANS_CHARGES)

More Information

Payment Order Checks [page 316]

Payment Engine (FS-PE)

328 PUBLIC Payment Processing (FS-PE-POP)
Ordering Party Item Checks [page 319]

Recipient Item Checks [page 322]

15.1.2.1.5 Reservation Item Checks

Use

You use these enrichment and validation checks to validate reservation items in Payment Engine during the
enrichment and validation process.

Prerequisites

• You have defined the general Customizing settings for enrichment and validation. For more information,
see Enrichment and Validation Checking [page 315] under Prerequisites.
• You have maintained the transaction type groups for enrichment and validation in Customizing
for Payment Engine under Payment Order Payment Order Enrichment and Validation Maintain
Enrichment and Validation Check Sets Maintain Transaction Type Groups for E&V .
• You have assigned transaction types for payment items to a transaction type group for enrichment and
validation in Customizing for Payment Engine under Payment Items Transaction Types and Transaction
Type Groups Define Transaction Types .
• You have assigned the transaction type groups for enrichment and validation to an enrichment and
validation check set in Customizing for Payment Engine under Payment Order Payment Order
Enrichment and Validation Maintain Enrichment and Validation Check Sets Assign E&V Check Set for
Payment Item .

Features

The following table describes the recipient item checks supported by Payment Engine.

Payment Item Checks — Recipient Items

Check Method Description

Check Recall Payment Item Checks whether a recall exists for the recipient item.

(CHECK_V_PI_RECALL)

Payment Engine (FS-PE)

Payment Processing (FS-PE-POP) PUBLIC 329
Check Method Description

Check Payment Item Priority Assigns the highest priority of either the payment item or
the value defined in the SLA.
(CHECK_V_PI_PRIORITY)

Mandatory Checks whether mandatory fields are filled in.

Fields Check

CHECK_V_MUST_FIELDS_PI

More Information

Payment Order Checks [page 316]

Ordering Party Item Checks [page 319]

Recipient Party Item Checks [page 322]

Cross Item Checks [page 327]

15.1.3 Enrichment and Validation Check Set

Definition

A group of checks used in payment processing to enrich and validate payment orders and payment items in
accordance with defined check rules.

The check set determines the sequence and mode in which the system executes the checks.

Use

In Payment Processing, the system retrieves the set of enrichment and validation checks defined for payment
order checking, ordering party item checking, recipient item checking, and cross-item checking during the
enrichment and validation process. The enrichment and validation check set ID is used to retrieve all the
checks grouped under this set of rules. For more information about enrichment and validation checks, see
Enrichment and Validation Check [page 313].

You can define and assign names to the enrichment and validation check set rules and assign rules to check
sets in Customizing for Payment Engine under Payment Order Payment Order Enrichment and Validation
Maintain Enrichment & Validation Check Sets .

Payment Engine (FS-PE)

330 PUBLIC Payment Processing (FS-PE-POP)
Structure

An enrichment and validation check set has the following structure:

• Clearing area
Specifies a legally independent organizational unit in Payment Engine.
• Check set ID
Identifies a rule that comprises customized checks for enrichment and validation.
• Rule type
Specifies the enrichment and validation rule type:
• Payment Order
This rule contains only inbound payment order checks.
• Ordering Item
This rule contains only inbound ordering party item checks.
• Recipient Party Item
This rule contains only inbound recipient item checks.
• Cross Item
This rule contains only inbound cross-item checks.
• Turnover Item
This rule contains only inbound turnover item checks.
• Outgoing PO
This rule contains only outgoing payment order checks.
• Outgoing PO ORP
This rule contains only outgoing ordering party item checks.
• Outgoing PO RCP
This rule contains only outgoing recipient item checks.
• Outgoing PO CLR
This rule contains only outgoing clearing item.
• Enable/Disable indicator
Determines whether rules are enabled or disabled.

Integration

You group a set of checks to be performed on a defined payment order (and its corresponding payment items)
in Payment Processing as part of the enrichment and validation process. This set of checks is performed under
the same enrichment and validation check set ID, which is determined for each object based on the attributes
stored in payment orders and payment items.

Payment Order Checks and Cross-Item Checks

The system uses the following payment order and system attributes to retrieve a set of checks to be executed
at payment order level and for cross-item checking.

• Clearing area
Specifies a legally independent organizational unit in Payment Engine.
• Payment order type group for enrichment and validation
Specifies the payment order type group for enrichment and validation.

Payment Engine (FS-PE)

Payment Processing (FS-PE-POP) PUBLIC 331
• Enrichment and validation set type
Specifies whether the enrichment and validation set type is executed for payment orders or for cross-item
checking.
• Execution time
Specifies when checks are carried out:
• E: at execution.
• S: at submission.
• X: at both submission and execution.
• Channel
Describes the method that can be used to transfer payment orders between financial institutions.
• Format
Defines the fields and the record structure of the payment order record set.
• Payment order enrichment and validation check set ID
Identifies an enrichment and validation check set rule of payment order checks.

You create and store an enrichment and validation check set for payment orders and cross-item checking
in Customizing for Payment Engine under Payment Order Payment Order Enrichment and Validation
Maintain Enrichment and Validation Check Sets Assign E&V Check Set for Payment Order .

Payment Item Checks

The system uses the following payment item and system attributes to retrieve a set of checks to be executed at
payment item level.

• Clearing area
Specifies a legally independent organizational unit in Payment Engine.
• Transaction type group for enrichment and validation
Specifies the transaction type group for enrichment and validation.
• Enrichment and validation set type
Specifies whether the enrichment and validation set type is executed for order party items or recipient
items.
• Execution time
Specifies when checks are carried out:
• E: at execution.
• S: at submission.
• X: at both submission and execution.
• Internal/External indicator
Specifies whether the entry refers to external or internal posting items on the recipient side.
• Channel
Describes the method that can be used to transfer payment orders between financial institutions.
• Format
Defines the fields and the record structure of the payment order record set.
• SAP Client Internal/External Flag
Indicates whether the SAP client is internal or external.
• Payment item enrichment and validation check set ID
Identifies an enrichment and validation check set rule of payment items checks.

Payment Engine (FS-PE)

332 PUBLIC Payment Processing (FS-PE-POP)
You create and store an enrichment and validation check set for payment items in Customizing for Payment
Engine under Payment Item Maintain Enrichment and Validation Check Sets Assign E&V Check Set for
Payment Item .

More Information

Check Processing Date [page 312]

15.1.4 Embargo Check

Use

This function performs an embargo check for specified payment-order or payment-item types in an external
system. The results of the check are returned to Payment Engine.

Prerequisites

Payment Engine is connected to an embargo system over a Business Application Programming Interface
(BAPI). For more information, see Connection to an Embargo System [page 170].

Features

• Depending on the defined check rules, the system determines whether a payment order or payment item
needs to be checked by the embargo system during enrichment and validation (E&V). The embargo check
can be configured for incoming or outgoing enrichment and validation check sets. If the payment order
or payment item requires embargo checking, the system sends it to the embargo system. Otherwise, the
system continues to process the payment order or payment item.
For more information, see Enrichment and Validation [page 311].
• If Payment Engine sends a payment order or payment item to an embargo system, the embargo system
performs the required check and sends a response to Payment Engine indicating whether the item can be
further processed.
If the embargo system indicates a critical item, it attaches an error flag to the payment item. Otherwise,
the embargo system resubmits the payment item for processing.
• The system sends critical payment orders or payment items to Exception Control for exception handling.
For more information, see Exception Control (FS-PE-EH) [page 265].

 Note

If you want an embargo check to be part of the outgoing enrichment and validation, make sure that it is not
also part of the incoming enrichment and validation. If is is defined in both, the system merely checks for an

Payment Engine (FS-PE)

Payment Processing (FS-PE-POP) PUBLIC 333
 embargo confirmation instead of carrying out a full check. Please take this into account when you configure
the enrichment and validation (E&V) checks.

15.1.5 Enrichment and Validation for Outgoing Payment

Orders

Use

Enrichment and validation for outgoing payment orders works in the same way as enrichment and validation
during payment processing.

Any outgoing payment orders or payment items can be validated using various checks that are carried out
when the outgoing payment order is processed (after payment order status 210 – ready for output manager
has been assigned). The system enriches payment information as required.

If any information is missing or incorrect, SAP Payment Engine uses an internal repair function to automatically
correct it. Alternatively, you can correct the data manually depending on the settings that have been configured
for exception handling. For more information, see Exception Control (FS-PE-EH) [page 265].

Prerequisites

• You have defined E&V checks in Customizing for Payment Engine under Payment Order Payment Order
Enrichment and Validation Maintain Enrichment and Validation Check Sets . In particular, you have
configured the following views:
• Maintain E&V Check Set
• Maintain Payment Order Type Group for E&V
• Assign E&V Check Set for Outgoing Payment Order
• Maintain Transaction Type Groups for E&V
• Assign E&V Check Set for Outgoing Payment Item
• Optional: If you want to use prenotes, you have selected the Prenote Required checkbox for the relevant
transaction type in Customizing for Payment Engine under Payment Item Transaction Types and
Transaction Type Groups Define Transaction Types . The checkbox is available in the Maintenance:
Transaction Types and Control area.

Features

Processing of Clearing Items

Payment Engine (FS-PE)

334 PUBLIC Payment Processing (FS-PE-POP)
If you want to use enrichment and validation for outgoing payment items, you have two ways of processing the
clearing item:

• By creating a prenote for clearing items

You can specify that a prenote is to be created for a transaction type of a clearing item. If you do so, a
prenote is created when the clearing item is processed.
Enrichment and validation takes place when the outgoing payment order is processed. If no errors are
found, the clearing item is posted after the outgoing payment order has been exported. If errors are
found and all of the recipient items in the payment order are incorrect, the clearing item is not posted. If
only some of the recipient items contain errors, they can be excluded from the outgoing payment order
(see Exception Handling). The clearing items for the remaining recipient items are posted. If the outgoing
payment order doesn't contain any more recipient items, the export is skipped.
• By direct posting and reprocessing if there are E&V errors
If you don't create prenotes for clearing items and errors occur in outgoing enrichment and validation, the
erroneous items can't be excluded from the outgoing payment order.

More Information

Enrichment and Validation Check Set [page 330]

Enrichment and Validation Checking [page 315]

15.1.5.1 Exception Handling in E&V for Outgoing Payment

Orders

Recipient Item Error Threshold

You can set an error threshold for recipient items in Customizing for Payment Engine under Payment Item
Payment Item Enrichment and Validation Maintain Error Threshold for Recipient Items . If the threshold
is reached and the percentage or number of incorrect items exceeds the permitted limit, an exception
is added to the payment order (error ID 000090). You can respond to this error in Exception Control
(transaction /PE1/EH) under Outgoing Payment Order Processing Outgoing Payment Order Enrichment
& Validation PO .

Exclude Recipient Items from Outgoing Payment Orders and Reprocess

Items

You can exclude incorrect recipient items from outgoing payment orders. To do so, select the response Exclude
RCP from Outgoing Order (EXCLUDE_PI) in Exception Control under Outgoing Payment Order Processing
Recipient Item Enrichment & Validation .

If you create prenotes for clearing items, any incorrect items are removed from the outgoing payment order.

Payment Engine (FS-PE)

Payment Processing (FS-PE-POP) PUBLIC 335
If the clearing item has already been posted, the items cannot be excluded. In this case, an error is added to
the item (error ID 002010) and the status is set to 76 (Redirected). You can define a response for the error in
Exception control under Outbound File Processing Recipient Item External Status update . For example,
you can select the response Reprocessing of outgoing PI (PI_REPRO) if you want to reprocess incorrect items.
In this case, a new inbound payment order is created.

More Information

Exception Control (FS-PE-EH) [page 265]

15.2 Routing Control Overview (FS-PE-RP)

Definition

This component determines the relevant business objects for further processing of payment items. These
business objects contain information relevant for transferring money from one financial institution to another.
During route processing, the system analyzes each payment item to evaluate how it should be processed. In
addition, it links various business objects to each payment item by using flexible rule sets.

More Information

Routing Control (FS-PE-RP) [page 205]

Payment Engine (FS-PE)

336 PUBLIC Payment Processing (FS-PE-POP)
16 Clearing Processing (FS-PE-CP)

Use

You use this component for final processing of internal and external payment items during clearing and
settlement.

Payment Engine supports the following clearing scenarios:

• Direct clearing
The financial institutions involved have a direct account relationship, typically a nostro or vostro account
relationship.
• Settlement between two financial institutions by means of a clearing institute
Neither financial institution has a clearing account with the other.
• Clearing with a separate cover provision
Neither financial institution has a clearing account with the other. Although the financial institutions
exchange information about the payment directly, the settlement amount is reached with the help of a
third party.

Integration

If no errors occur in Payment Processing, final processing of a payment takes place in Clearing Processing.
The type of processing depends on the information defined in Routing Control (route, clearing agreement,
customer agreement, value date agreement) and the payment characteristics (payment order and payment
item attributes such as currency, value date, and payment type). For more information, see Payment
Processing (FS-PE-POP) [page 309] and Routing Control (FS-PE-RP) [page 205].

If an error occurs during clearing and settlement, the system sends a message with an error code to Exception
Control. For more information about error handling, see Exception Control (FS-PE-EH) [page 265].

The Clearing Processing component is typically connected to one or more account management systems over
Account Management Proxy. For more information, see Account Management Proxy (FS-PE-AMP) [page 364].

Features

The system processes payment items in one of the following ways:

• Direct clearing
• Direct posting of internal payment items
The system forwards payment items directly to an internal account management system.
• Single-item forwarding of external payment items

Payment Engine (FS-PE)

Clearing Processing (FS-PE-CP) PUBLIC 337
 The system forwards payment items to an outgoing channel in a new outgoing payment order and
transfers them to File Handler for output processing. For more information, see File Handler (FS-PE-
FH) [page 289].

 Note

For more information, see Direct Clearing [page 357].

• Queuing
The system parks single items in a queue for later release.
You can release payment items from a queue manually or automatically based on a time stamp. When you
release a payment item from a queue, the system posts the sum to the relevant clearing account (nostro or
vostro account).
For more information, see Queue [page 339].
• Collection
Payment Engine uses the following collector categories to collect payment items when a recipient requests
that the financial institution batch multiple payments into one sum instead of posting every single item to
the account individually:
• Customer collector for internal payment items
The system assigns internal payment items to a collector based on the collection criteria defined in the
clearing agreement. When the collector is finally processed, the system posts a single clearing item to
an internal account and transfers a payment advice to File Handler for output processing.

 Note

If the payment items have more than one value date, multiple payment items are created.

If multi-collection is enabled, several payment advices are combined in one payment advice at a
later point in time.

• Clearing collector for external payment items

The system assigns external payment items to a collector based on the collection criteria defined in
the clearing agreement. When the collector is finally processed, the system posts a clearing item to an
internal clearing account (a nostro or vostro account) and transfers a new outgoing payment order to
File Handler for output processing.
For more information, see Collector [page 346].

 Note

Queues and collectors both collect payment items; however, the system transfers payment items collected
in queues as single, separate posting requests to an account management system for processing at a
defined clearing time (date, hour, minute).

Payment Engine provides functions to perform the following tasks manually:

• Assign payment items to collectors and queues

For more information, see Assign Payment Items to Collector/Queue [page 358].
• Close collectors and queues
For more information, see Close Collector/Queue [page 361].
• Initiate final processing of collectors and payment items parked in queues
For more information, see Final Processing (Collector/Queue) [page 363].

Payment Engine (FS-PE)

338 PUBLIC Clearing Processing (FS-PE-CP)
16.1 Queue

Definition

A collection of individual payment items that are parked for manual release or automatic release at a scheduled
processing time, for example, during end-of-day processing.

Use

You use queues for the following reasons:

• You want to check payment items individually or manually by group (for example, to perform a liquidity
check) before posting and sending them for output processing.
• You want to release payment items manually to supervise the release.
• You want to schedule processing of payment items at a defined time and not immediately.

 Note

You define whether payment items are collected in queues in clearing agreements. For more information,
see Setting Up Queues and Collectors [page 342].

Payment items parked in queues are sent individually in an outgoing payment order or a posting item for
further processing.

In queues with external payment items, one clearing item is created for each payment item and no collective
posting takes place.

You can assign similar payment items to the same queue, for example, payment items with the same value date
or processing date or payment items of the same type. For more information, see Assign Payment Items to
Collector/Queue [page 358].

When the processing date and time are reached for a payment item, the payment items are removed from the
queue for processing and posting.

Payment Engine uses the following types of queues:

• Functional queue
The system sends payment items to a functional queue based on the settings in the clearing agreement.
These payment items remain in this queue until a predefined time has been reached to trigger further
actions, such as reassignment of payment items.
Based on the setting in the clearing agreement, a reservation request can be sent when payment items are
assigned to a functional queue.
When payment items are removed from a queue, the payment items are posted individually by using the
original clearing agreement or by using an alternative clearing agreement based on the setting in the
clearing agreement.
• Technical queue
The system sends payment items to a technical queue if the setting in the clearing agreement locks
forwarding of payment items via the defined route. These payment items remain in this queue until the

Payment Engine (FS-PE)

Clearing Processing (FS-PE-CP) PUBLIC 339
 lock has been disabled or until the payment items are manually released or rerouted to a different clearing
agreement.
When payment items are assigned to a technical queue, a reservation request is always sent.
When payment items are removed from a queue, the payment items are posted individually by using the
original clearing agreement or by using an alternative clearing agreement based on the setting in the
clearing agreement.

Structure

Queue Screen

The queue screen contains the following screen areas:

• Search area
You can enter a text to search for clearing agreements currently loaded in the navigation tree.
• Navigation tree
Displays collection types, combinations of routes and clearing agreements, collection categories, and
existing queues for the selected clearing area in a hierarchical structure.
• Business object
Depending on the node that you select from the navigation tree, displays details about:
• Collection type
Displays a list of existing queues in SAP List Viewer.
• Combination of route and clearing agreement
Displays the collection information defined in the clearing agreement for a combination of route
and clearing agreement. For more information, see Clearing Agreement [page 219] under Collector
Processing (Collector Only).
• Collection category
Displays the characteristics that define the queue category.
• Queue
Displays details about the selected processing sequence created for a queue category.

Queue Details

On the queue screen, you can find the following business object information:

Header Data

• Collection type (queue or collector)

• Collector processing date
Specifies the date on which the queue was used for processing.
• Collector number
Determined by a number range that you define in Customizing for Payment Engine under Clearing
Maintain Number Ranges for Collectors .
• Sequence
Specifies a processing sequence within a queue category.
• Direction
Displays whether the queue is intended for processing internal or external payments.

Basic Data

Payment Engine (FS-PE)

340 PUBLIC Clearing Processing (FS-PE-CP)
• Status information
Displays the status of the queue. Only the statuses Open and Closed are relevant for queues.
• Closing information
Displays the reason for closing a queue.
If a queue is open and is scheduled to close according to time-based criteria, this area also displays the
time at which the queue status was last checked.
If a queue is closed, this area also displays the user who closed the queue and the time at which the queue
closed.
• Check of required clearing times
• Current attributes
Displays the total debit amount and the total credit amount for the payment items in the queue in the
collector currency. Also displays the number of payment items in the queue for a debit or a credit and the
minimum number of payment items required to close the queue.
• General attributes
Displays the following attributes:
• Transaction currency
• Value date
In the clearing agreement, you specify whether payment items with different value dates can be
assigned to the same queue or collector.
• Payment item limit (only relevant for collectors)
• Multi collection (only relevant for collectors)
• Payment item category
• Debit or credit transaction
In the clearing agreement, you specify whether payment items for debit and credit can be assigned to
the same queue or collector.
• Minimum amount that a queue or collector must contain before closing
• Clearing item posted (only relevant for collectors)
• Clearing account
Displays the account details of the recipient or of a clearing account.

Administration Data

This tab page displays the user who created or last changed the queue and the time and date when the queue
was created and last changed.

Integration

The Poller report picks up payment items parked in a queue for processing once their scheduled processing
time and date has been reached.

You can access the Poller report on the SAP Easy Access screen by choosing Payment Engine Periodic
Processing Processes Execute Processes (transaction /PE1/POLLER).

Payment Engine (FS-PE)

Clearing Processing (FS-PE-CP) PUBLIC 341
16.1.1 Setting Up Queues and Collectors

Prerequisites

• You have defined the release workflow in Customizing for Payment Engine under Routing Control
Release Clearing Agreement and Rule Set .
• You have the necessary rights to change and create a clearing agreement and its rules.
• You have display rights for the selected clearing area.
• If delays are expected, you have maintained how the planned execution time of an outgoing
payment order is calculated in the external clearing agreement. On the SAP Easy Access screen,
choose Payment Engine Master Data Routing Control Manage Routes and Clearing Agreements
(transaction /PE1/RN) and under Data for Payment Order to be Forwarded, choose Executed On. For more
information, see Clearing Agreement [page 219] under External Clearing Agreement (External Only).

Context

To determine that the system automatically parks payment items in queues for later release or that the system
bundles payment items in collectors for collective posting in a single payment order, you need to define the
settings in the corresponding clearing agreements.

Procedure

1. On the SAP Easy Access screen, choose Payment Engine Master Data Routing Control Manage
Routes and Clearing Agreements (transaction /PE1/RN) and enter a clearing area.

 Note

You can show or hide the search area and navigation tree by choosing the Switch Overview Tree On/Off
pushbutton.

2. From the navigation tree, double-click the clearing agreement for which you want to define a queue or
collector.
3. On the Basic Data tab page, in the Clearing Scenario screen area, choose Collect Items.

The Collector Process. tab page appears.

4. On the Collector Process. tab page, in Collection Type, choose Queue or Collector.

For more information about the Collector Process. tab page, see Clearing Agreement [page 219] under
Collector Processing (Collector Only).
5. Define the following settings:

Payment Engine (FS-PE)

342 PUBLIC Clearing Processing (FS-PE-CP)
 • Separation criteria for assignment
Define whether a collection of payment items is to join an existing collector or queue or whether a new
collector or queue is to be generated for any of the following conditions:
• Different value dates
• Different processing dates
• Different due dates and direct debit types

 Note

You can separate payment items by due date and direct debit types in the context of the Single
Euro Payments Area (SEPA).

• Different payment item types

• Different original message IDs

 Note

You can separate payment items by original message ID in the context of requests for payment
cancellation. For more information, see Request for Cancellation [page 106].

• Multi-collection (internal clearing agreement only)

You use this indicator to specify whether multi-collection is allowed.
• Different Eurogiro product codes
• Closing criteria
You can define whether a queue or collector is to close according to time-based conditions or content-
based conditions

 Note

In addition to time-based closing conditions, the system closes clearing collectors on a planned
closing date to ensure that the outgoing payment order is sent in time to meet the due date. The
planned closing date equals the due date plus/minus the offset defined in the external clearing
agreement.

• Conditions for final processing

You can define a planned clearing time for internal queues/collectors, in particular, to support account
management systems that do not support the posting of items with a future posting date.
6. Save the object and trigger the release process by choosing the Release pushbutton.

Results

You have defined that the system will assign payment items that are assigned to a specific clearing agreement
and that meet the defined collection criteria to a queue or a collector.

You can display and manage queues and collectors. On the SAP Easy Access screen, choose Payment Engine
Clearing Manage Collectors and Queues (transaction /PE1/CP_COLL).

Payment Engine (FS-PE)

Clearing Processing (FS-PE-CP) PUBLIC 343
Next Steps

Queue [page 339]

Collector [page 346]

16.1.2 Managing Queues

Use

You typically process queues in the following scenarios according to the configuration of the clearing
agreements and the clearing agreement type:

• Single posting of ordering party items and recipient items that have been assigned to a queue (functional
queue)
• Reservation of ordering party items and recipient items during queue assignment and single posting of
these items (functional queue)
• Removal of ordering party items and recipient items from a queue by using the same route and clearing
agreement
• Removal of ordering party items and recipient items from a queue by using a different route and clearing
agreement
• Deletion of a reservation while removing payment items from a queue
• Assignment of ordering party items and recipient items to a queue with a reservation due to an outgoing
order lock (technical queue)
• Removal of order party items and recipient items from a queue by using the same route and clearing
agreement (technical queue)
• Removal of order party items and recipient items from a queue by using a different route and clearing
agreement (technical queue)

You can manage customer queues for internal payment items and clearing queues for external payment items.

Prerequisites

The following prerequisites must be met:

• You have display rights for the selected clearing area.

• You have maintained account symbols in Customizing for Payment Engine under Clearing Define and
Maintain Account Symbols .
• You have defined the settings for queues. On the SAP Easy Access screen, choose Payment Engine
Master Data Routing Control Manage Routes and Clearing Agreements (transaction /PE1/RN).
• The queues that you want to process have the status Open.

Payment Engine (FS-PE)

344 PUBLIC Clearing Processing (FS-PE-CP)
Procedure

1. On the SAP Easy Access screen, choose Payment Engine Clearing Manage Collectors and Queues
(transaction /PE1/CP_COLL).
2. Enter a clearing area and continue.

Displaying Queues

You can display information related to queues by doing the following:

• To display a list of available queues and details about each queue in the navigation tree, double-click
Customer Queues or Clearing Queues.

 Note

You can show or hide the search area and navigation tree by choosing the Switch Overview Tree On/Off
pushbutton.

• Expand the navigation tree to display the available combinations of route and clearing agreement, queue
categories, and sequences.

 Note

The system creates sequences after the Update and Close Collector function is run. You access
this function on the SAP Easy Access screen by choosing Payment Engine Periodic Processing
Processes Execute Processes (transaction /PE1/POLLER).

• Double-click a combination of route and clearing agreement to display the settings defined in the clearing
agreement for the collection of payment items in queues.
• Double-click a queue category to display the characteristics that define the queue category, and choose
the Assigned Items pushbutton to display the payment items that are currently assigned to the queues in
this queue category.

 Note

When the Update and Close Collector function is run, the system assigns payment items to queues
according to the closing criteria defined in the clearing agreement and payment items are not assigned
to the queue category but to a sequence.

• From the navigation tree, double-click a queue to display all basic data about the queue sequence.
Choose the Assigned Items pushbutton to display the payment items that are currently assigned to this
sequence.
• Choose Extras Change Data Source Archive to display archived payment collector data, including
customer collectors, clearing collectors, and queues.

For more information about the queue screen, see Queue [page 339] under Structure.

Changing Queue Settings

You typically define clearing scenarios that use queues in clearing agreements. However, you can also display
and change the settings in clearing agreements by doing the following:

1. From the navigation tree, double-click a queue category.

2. On the Class. Characteristics tab page, next to the Clearing Agreement field, choose the Detail View
Clearing Agreement icon.

Payment Engine (FS-PE)

Clearing Processing (FS-PE-CP) PUBLIC 345
 The clearing agreement opens and the Collector Process. tab page is displayed.
3. Switch to change mode and change the settings.
For more information, see Setting Up Queues and Collectors [page 342].
4. Save the object and trigger the release process by choosing the Release pushbutton.

Processing Individual Payment Items in a Queue

You can process individual payment items in a queue manually.

1. From the navigation tree, double-click the queue in which the payment item you want to release is parked
and choose the Assigned Items pushbutton.
2. Select a payment item and do one of the following:
• To post the payment item, choose the Release Item pushbutton.
• To remove the payment item from the queue, choose the Reassign Item pushbutton.

 Note

You can also select more than one payment item for processing.

Processing All Payment Items in a Queue

You can process all payment items in a queue manually. For more information, see:

• Assign Payment Items to Collector/Queue [page 358]

• Close Collector/Queue [page 361]
• Final Processing (Collector/Queue) [page 363]

 Note

You can display an overview of status transitions for collectors and queues in Customizing for Payment
Engine under Tools Functional Monitoring Display Status Transitions Display Status Transitions of
Collectors .

16.2 Collector

Definition

A collection of payment items based on a clearing agreement that has been set up with a business partner.

Use

You use collectors to bundle payment items for collective posting to internal accounts (customer collector)
or to generate a single outgoing payment order to send to a financial institution or clearing house (clearing
collector). The outgoing payment order contains information about the individual payment items required for
further processing by a format converter. The payment items are posted as one total sum.

Payment Engine (FS-PE)

346 PUBLIC Clearing Processing (FS-PE-CP)
  Note

You define whether payment items are collected in collectors in clearing agreements. For more information,
see Setting Up Queues and Collectors [page 350].

A reservation request can be sent to an account management system to ensure that enough money is available
in the account to cover the sum of the payment items to be posted. Posting of payment items in a collector can
be simulated before payment items are posted. The posting is done with a corresponding clearing item that
covers the total amount of payment items in the collector. Reservation and posting simulation are performed
when the corresponding settings are defined in the relevant clearing agreement and in Customizing. You can
also complete mandates for SEPA direct debits that have been collected, as the mandate information is not
transferred to the account management system in a collective posting.

For more information, see Reservation [page 369], Posting Simulation [page 366], and Completing Mandates
[page 381].

Payment Engine uses the following types of collectors:

• Customer collector for internal payment items

Used to collect recipient items, ordering party items, clearing items, and turnover items to post them later
in a compressed form to an internal account as one total sum.

 Example

Payments to a utility company

Customers usually pay their bills on a specified date or within a period defined by the utility company.
Rather than send thousands of individual payments, the items are collected and their sums are added
together. A single payment order is then sent to the company in the form of a payment advice. This
payment advice contains information about the individual payment items in the customer collector.

For more information, see Managing Customer Collectors [page 352].

• Clearing collector for external payment items
Used to collect recipient items to process payment transactions with other financial institutions
collectively during clearing of payment orders using bank clearing accounts.
For more information, see Managing Clearing Collectors [page 354].

In addition, you can also use the multi-collection function to bundle collectors that have the same account
details and that have been closed according to non-time-based criteria in a common logical output file. For
more information about closing criteria, see Close Collector/Queue [page 361].

You can assign similar payment items to the same collector, for example, payment items with the same value
date, processing date, due date and direct debit type, or of the same payment item type. For more information,
see Assign Payment Items to Collector/Queue [page 358].

Structure

Collector Screen

The collector screen is organized in the following screen areas:

• Search area

Payment Engine (FS-PE)

Clearing Processing (FS-PE-CP) PUBLIC 347
 You can enter a text to search for clearing agreements currently loaded in the navigation tree.
• Navigation tree
Displays collection types, combinations of routes and clearing agreements, collection categories, and
existing collectors for the selected clearing area in a hierarchical structure.

 Note

If collection by due date and direct debit type is enabled, the due date and direct debit type are
displayed for the collector sequences.

• Business object
Depending on the node that you select from the navigation tree, displays details about:
• Collection type
Displays a list of existing collectors in SAP List Viewer.
• Combination of route and clearing agreement
Displays the collection information defined in the clearing agreement for a combination of route
and clearing agreement. For more information, see Clearing Agreement [page 219] under Collector
Processing (Collector Only).
• Collection category
Displays the characteristics that define the collector category.
• Collector
Displays details about the selected processing sequence created for a collector category.

Collector Details

On the collector screen, you can find the following business object information:

Header Data

• Collection type (queue or collector)

• Collector processing date
Specifies the date on which the collector was used for processing.
• Collector number
Determined by a number range that you can define in Customizing for Payment Engine under Clearing
Maintain Number Ranges for Collectors .
• Sequence
Specifies a processing sequence within a collector.
• Direction
Displays whether the collector is intended for processing internal or external payments.

Basic Data

• Status information
Displays the status of the collector. A collector can have one of the following statuses:
• Category
• Open
• Closed
• Final Processing Started
• Completed and Processed
• Waiting for Asynchronous Processing

Payment Engine (FS-PE)

348 PUBLIC Clearing Processing (FS-PE-CP)
 • Final Category
In a multi-collection scenario, also displays the type of collector processing: Post Items Collectively, Post
Collected Items Individually, Several Collector Items Not Posting-Relevant.
• Closing information
Displays the reason for closing a collector.
If a collector is open and is scheduled to close according to time-based criteria, this area also displays the
time at which the collector status was last checked.
If a collector is closed, this area also displays the user who closed the collector and the time at which the
collector closed.
• Check of required clearing times
• Current attributes
Displays the total debit amount and the total credit amount for the payment items in the collector in the
collector currency. Also displays the number of payment items in the collector for a debit or a credit and
the minimum number of payment items required to close the collector.
• General attributes
Displays the following attributes:
• Transaction currency
• Value date
In the clearing agreement, you specify whether payment items with different value dates can be
assigned to the same queue or collector.
• Payment item limit (only relevant for collectors)
Specifies the maximum number of items in a collector before final processing is initiated.
• Multi-collection (only relevant for collectors)
• Payment item category
• Debit or credit transaction
In the clearing agreement, you specify whether payment items for debit and credit can be assigned to
the same queue or collector
• Minimum amount that a queue or collector must contain before closing
• Clearing item posted (only relevant for collectors)
• Due date (only if collection by due date and direct debit type is enabled)
• Direct debit type (only if collection by due date and direct debit type is enabled)
• Planned closing date
• Clearing account
Displays the account details of the recipient or of a clearing account.

Associated Payment Order

This tab page displays the payment order associated with the collector, which summarizes all information
about the payment items bundled in the collector.

In a multi-collection scenario, this tab page displays a list of associated payment orders and the payment order
details.

Administration Data

This tab page displays the user who created or last changed the collector and the time and date when the
collector was created and last changed.

Payment Engine (FS-PE)

Clearing Processing (FS-PE-CP) PUBLIC 349
16.2.1 Setting Up Queues and Collectors

Prerequisites

• You have defined the release workflow in Customizing for Payment Engine under Routing Control
Release Clearing Agreement and Rule Set .
• You have the necessary rights to change and create a clearing agreement and its rules.
• You have display rights for the selected clearing area.
• If delays are expected, you have maintained how the planned execution time of an outgoing
payment order is calculated in the external clearing agreement. On the SAP Easy Access screen,
choose Payment Engine Master Data Routing Control Manage Routes and Clearing Agreements
(transaction /PE1/RN) and under Data for Payment Order to be Forwarded, choose Executed On. For more
information, see Clearing Agreement [page 219] under External Clearing Agreement (External Only).

Context

To determine that the system automatically parks payment items in queues for later release or that the system
bundles payment items in collectors for collective posting in a single payment order, you need to define the
settings in the corresponding clearing agreements.

Procedure

1. On the SAP Easy Access screen, choose Payment Engine Master Data Routing Control Manage
Routes and Clearing Agreements (transaction /PE1/RN) and enter a clearing area.

 Note

You can show or hide the search area and navigation tree by choosing the Switch Overview Tree On/Off
pushbutton.

2. From the navigation tree, double-click the clearing agreement for which you want to define a queue or
collector.
3. On the Basic Data tab page, in the Clearing Scenario screen area, choose Collect Items.

The Collector Process. tab page appears.

4. On the Collector Process. tab page, in Collection Type, choose Queue or Collector.

For more information about the Collector Process. tab page, see Clearing Agreement [page 219] under
Collector Processing (Collector Only).
5. Define the following settings:

Payment Engine (FS-PE)

350 PUBLIC Clearing Processing (FS-PE-CP)
 • Separation criteria for assignment
Define whether a collection of payment items is to join an existing collector or queue or whether a new
collector or queue is to be generated for any of the following conditions:
• Different value dates
• Different processing dates
• Different due dates and direct debit types

 Note

You can separate payment items by due date and direct debit types in the context of the Single
Euro Payments Area (SEPA).

• Different payment item types

• Different original message IDs

 Note

You can separate payment items by original message ID in the context of requests for payment
cancellation. For more information, see Request for Cancellation [page 106].

• Multi-collection (internal clearing agreement only)

You use this indicator to specify whether multi-collection is allowed.
• Different Eurogiro product codes
• Closing criteria
You can define whether a queue or collector is to close according to time-based conditions or content-
based conditions

 Note

In addition to time-based closing conditions, the system closes clearing collectors on a planned
closing date to ensure that the outgoing payment order is sent in time to meet the due date. The
planned closing date equals the due date plus/minus the offset defined in the external clearing
agreement.

• Conditions for final processing

You can define a planned clearing time for internal queues/collectors, in particular, to support account
management systems that do not support the posting of items with a future posting date.
6. Save the object and trigger the release process by choosing the Release pushbutton.

Results

You have defined that the system will assign payment items that are assigned to a specific clearing agreement
and that meet the defined collection criteria to a queue or a collector.

You can display and manage queues and collectors. On the SAP Easy Access screen, choose Payment Engine
Clearing Manage Collectors and Queues (transaction /PE1/CP_COLL).

Payment Engine (FS-PE)

Clearing Processing (FS-PE-CP) PUBLIC 351
Next Steps

Queue [page 339]

Collector [page 346]

16.2.2 Managing Customer Collectors

Use

You typically process customer collectors in the following scenarios according to the configuration of the
clearing agreements and the clearing agreement type:

• Posting simulation, reservation, and posting of internal recipient items (internal customer clearing
agreement)
• Posting simulation, reservation, and collective posting with an alternate clearing agreement for internal
recipient items
• Posting simulation, reservation, and single posting after removal of internal recipient items from a
customer collector
• Posting simulation, reservation, and posting of a customer collector based on separation criteria, such as
value date, credit or debit transaction
• Posting simulation, reservation, and posting of a customer collector based on volume-based or time-based
closing criteria

Prerequisites

You have display rights for the selected clearing area.

You have maintained account symbols in Customizing for Payment Engine under Clearing Define and
Maintain Account Symbols .

You have defined the settings for customer collectors. On the SAP Easy Access screen, choose Payment
Engine Master Data Routing Control Manage Routes and Clearing Agreements (transaction /PE1/RN).

Procedure

1. On the SAP Easy Access screen, choose Payment Engine Clearing Manage Collectors and Queues
(transaction /PE1/CP_COLL).
2. Enter a clearing area and continue.

Displaying Customer Collectors

Payment Engine (FS-PE)

352 PUBLIC Clearing Processing (FS-PE-CP)
You can display information related to customer collectors by doing the following:

• From the navigation tree, double-click Customer Collector to display a list of available customer collectors
and details about each customer collector.

 Note

You can show or hide the search area and navigation tree by choosing the Switch Overview Tree On/Off
pushbutton.

• Expand the navigation tree to display the available combinations of route and clearing agreement, collector
categories, and sequences.

 Note

The system creates sequences after the Update and Close Collector function is run. You access
this function on the SAP Easy Access screen by choosing Payment Engine Periodic Processing
Processes Execute Processes (transaction /PE1/POLLER).

• Double-click a combination of route and clearing agreement to display the settings defined in the clearing
agreement for the collection of payment items in customer collectors.
• Double-click a collector category to display the characteristics that define the collector category, and
choose the Assigned Items pushbutton to display the payment items that are currently assigned to this
collector category.

 Note

When the Update and Close Collector function is run, the system bundles payment items according
to the closing criteria defined in the clearing agreement and payment items are not assigned to the
collector category but to a sequence.

• From the navigation tree, double-click a collector sequence to display all basic data about the sequence
and information about the associated payment order.
Choose the Assigned Items pushbutton to display the payment items that are currently assigned to this
sequence.
• Choose Extras Change Data Source Archive to display archived payment collector data, including
customer collectors, clearing collectors, and queues.

For more information about the collector screen, see Collector [page 346] under Structure.

Changing Customer Collector Settings

You typically define clearing scenarios that use collectors in clearing agreements. However, you can also
display and change the settings in clearing agreements by doing the following:

1. From the navigation tree, double-click a customer collector category.

2. On the Class. Characteristics tab page, next to the Clearing Agreement field, choose the Detail View
Clearing Agreement icon.
The clearing agreement opens and you can display the clearing agreement on the Internal Clearing
Agreem. tab page and the settings for collection on the Collector Process. tab page.
For more information, see Clearing Agreement [page 219].
3. Switch to change mode and change the settings.
For more information, see Setting Up Queues and Collectors [page 350].
4. Save the object and trigger the release process by choosing the Release pushbutton.

Payment Engine (FS-PE)

Clearing Processing (FS-PE-CP) PUBLIC 353
Processing Individual Payment Items in a Customer Collector

You can reprocess payment items assigned to a customer collector manually.

1. From the navigation tree, double-click the collector that contains the payment item you want to process
and choose the Assigned Items pushbutton.
2. Select a payment item and choose the Reassign Item pushbutton to remove the payment item from the
customer collector.

 Note

You can also select more than one payment item for processing.

3. Reroute the payment item for reprocessing or reprocess the payment item within the same clearing
agreement.
The system checks whether the route and clearing agreement are both active.

 Note

You can only reassign payment items that are assigned to a collector category but have not yet been
assigned to a sequence or payment items that are assigned to an open sequence.

You can only reroute payment items assigned to open collectors.

Processing All Payment Items in a Customer Collector

You can process all payment items in a customer collector manually. For more information, see:

• Assign Payment Items to Collector/Queue [page 358]

• Close Collector/Queue [page 361]
• Final Processing (Collector/Queue) [page 363]

 Note

You can display an overview of status transitions for collectors and queues in Customizing for Payment
Engine under Tools Functional Monitoring Display Status Transitions Display Status Transitions of
Collectors .

16.2.3 Managing Clearing Collectors

Use

You typically process clearing collectors in the following scenarios according to the configuration of the clearing
agreements and the clearing agreement type:

• Posting simulation, reservation, and collective posting of external recipient items (external clearing
agreement)
• Posting simulation, reservation, and posting of a clearing collector based on separation criteria, such as
value date, credit or debit transaction
• Posting simulation, reservation, and posting of a clearing collector based on volume-based or time-based
closing criteria

Payment Engine (FS-PE)

354 PUBLIC Clearing Processing (FS-PE-CP)
• Posting simulation, reservation, and posting of a clearing collector based on due date and direct debit type
• Decoupling of clearing items in the event of non-availability of a connected account management system
(external clearing agreement)

Prerequisites

You have display rights for the selected clearing area.

You have maintained account symbols in Customizing for Payment Engine under Clearing Define and
Maintain Account Symbols .

You have defined the settings for clearing collectors. On the SAP Easy Access screen, choose Payment
Engine Master Data Routing Control Manage Routes and Clearing Agreements (transaction /PE1/RN).

Procedure

1. On the SAP Easy Access screen, choose Payment Engine Clearing Manage Collectors and Queues
(transaction /PE1/CP_COLL).
2. Enter a clearing area and continue.

Displaying Clearing Collectors

You can display information related to clearing collectors by doing the following:

• From the navigation tree, double-click Clearing Collector or to display a list of available clearing collectors
and details about each clearing collector.

 Note

You can show or hide the search area and navigation tree by choosing the Switch Overview Tree On/Off
pushbutton.

• Expand the navigation tree to display the available combinations of route and clearing agreement, collector
categories, and sequences.

 Note

The system creates sequences after the Update and Close Collector function is run. You access
this function on the SAP Easy Access screen by choosing Payment Engine Periodic Processing
Processes Execute Processes (transaction /PE1/POLLER).

 Note

If you enable collection by due date and direct debit type, the due date and direct debit type are
displayed for the collector sequences.

• Double-click a combination of route and clearing agreement to display the settings defined in the clearing
agreement for the collection of payment items in clearing collectors.

Payment Engine (FS-PE)

Clearing Processing (FS-PE-CP) PUBLIC 355
• Double-click a collector category to display the characteristics that define the collector category, and
choose the Assigned Items pushbutton to display the payment items that are currently assigned to the
clearing collectors in this collector category.

 Note

When the Update and Close Collector function is run, the system bundles payment items according
to the closing criteria defined in the clearing agreement and payment items are not assigned to the
collector category but to a sequence.

• From the navigation tree, double-click a collector sequence to display all basic data about the sequence
and information about the associated payment order.
Choose the Assigned Items pushbutton to display the payment items that are currently assigned to this
sequence.
• Choose Extras Change Data Source Archive to display archived payment collector data, including
customer collectors, clearing collectors, and queues.

For more information about the collector screen, see Collector [page 346] under Structure.

Changing Clearing Collector Settings

You typically define clearing scenarios that use collectors in clearing agreements. However, you can also
display and change the settings in clearing agreements by doing the following:

1. From the navigation tree, double-click a clearing collector category.

2. On the Class. Characteristics tab page, next to the Clearing Agreement field, choose the Detail View
Clearing Agreement icon.
The clearing agreement opens and you can display the clearing agreement on the External Clearing
Agreem. tab page and the settings for collection on the Collector Process. tab page.
For more information, see Clearing Agreement [page 219].
3. Switch to change mode and change the settings.
For more information, see Setting Up Queues and Collectors [page 350].
4. Save the object and trigger the release process by choosing the Release pushbutton.

Processing Individual Payment Items in a Clearing Collector

You can reprocess payment items assigned to a clearing collector manually.

1. From the navigation tree, double-click the collector that contains the payment item you want to process
and choose the Assigned Items pushbutton.
2. Select a payment item and choose the Reassign Item pushbutton to remove the payment item from the
clearing collector.

 Note

You can also select more than one payment item for processing.

3. Reroute the payment item for reprocessing or reprocess the payment item within the same clearing
agreement.
The system checks whether the route and clearing agreement are both active.

 Note

You can only reassign payment items that are assigned to a collector category but have not yet been
assigned to a sequence or payment items that are assigned to an open sequence.

Payment Engine (FS-PE)

356 PUBLIC Clearing Processing (FS-PE-CP)
 You can only reroute payment items assigned to open collectors.

Processing All Payment Items in a Clearing Collector

You can process all payment items in a clearing collector manually. For more information, see:

• Assign Payment Items to Collector/Queue [page 358]

• Close Collector/Queue [page 361]
• Final Processing (Collector/Queue) [page 363]

 Note

You can display an overview of status transitions for collectors and queues in Customizing for Payment
Engine under Tools Functional Monitoring Display Status Transitions Display Status Transitions of
Collectors .

16.3 Direct Clearing

Use

You can use this process to forward single payment items to an internal account management system and to
forward single external payment items to an outgoing channel in a new outgoing payment order.

You can process single payment items manually or configure the system to batch process payment items on a
regular basis.

Prerequisites

You have defined how the system processes different types of payment items in the clearing agreements. On
the SAP Easy Access screen, choose Payment Engine Master Data Routing Control Manage Routes and
Clearing Agreements (transaction /PE1/RN).

For more information, see Clearing Agreement [page 219].

Process

Direct Posting of Internal Payment Items

1. After route processing, the system transfers payment items to Clearing Processing.
2. Based on the settings in the route and the clearing agreement, the system determines the following:
• That the payment items are internal

Payment Engine (FS-PE)

Clearing Processing (FS-PE-CP) PUBLIC 357
 • That the payment items are not to be assigned to a queue or collector
• The internal account management system to which the payment items are to be forwarded
3. If defined, the system calls up the credit-limit-check application to authorize a payment.
4. After the authorization is received, the system sends a posting request to an internal account management
system.
5. The internal account management system posts the payment to the beneficiary account.

Single-Item Forwarding of External Payment Items

1. After route processing, the system transfers payment items to Clearing Processing.
2. Based on the settings in the route and the clearing agreement, the system determines the following:
• That the payment items are external
• That the payment items are not to be assigned to a queue or collector
• The internal account management system to which the payment items are to be forwarded
3. Output Manager creates a new outgoing payment order in which the financial institution is the ordering
party requesting the recipient (a clearing system or external financial institution) to execute the payment.
Output Manager sends the outgoing payment order in a file. For more information, see Output Manager
[page 295].
4. The system creates a clearing item and posts it to the internal clearing account (nostro or vostro account),
which is linked to the outgoing clearing system or recipient financial institution.
5. The system routes the internal clearing item as a posting request to the relevant external account
management system.
6. The external account management system posts the payment to the beneficiary account.

16.4 Assign Payment Items to Collector/Queue

Use

You can use this function to assign payment items to a collector or a queue during the clearing and settlement
process and to manage the clearing process, for example, to consolidate payment transactions for a given
period into one payment unit.

Routing Control assigns payment items with references to a clearing agreement and a route. For example, if the
clearing agreement is of type collector, the system searches for an open collector of the clearing agreement
that has exactly the same (separation) attributes as defined in the payment items. If no collectors exist, the
system opens a new collector.

Integration

The system assigns payment items to a collector category or a queue category based on the separation criteria
defined in clearing agreements. If at least one of the attributes in a payment item does not match the criteria
defined for the open categories, the system generates a new collector category or queue category with a new
collector number. It then assigns the payment item to this category.

Payment Engine (FS-PE)

358 PUBLIC Clearing Processing (FS-PE-CP)
Each collector category and queue category is given a collector number based on a number range that you
have defined in Customizing.

The system assigns the payment items to new or existing sequences depending on the closing criteria defined
for the category in the clearing agreement. For more information, see Clearing Agreement [page 219].

Prerequisites

You have defined whether a collection of payment items is to join an existing collector or queue or whether
a new collector or queue is to be generated for different conditions: On the SAP Easy Access screen,
choose Payment Engine Master Data Routing Control Manage Routes and Clearing Agreements
(transaction /PE1/RN).

For more information, see Setting Up Queues and Collectors [page 342].

You have mapped the error codes of the account management system to the error codes used in Payment
Engine and specified the relevant error ID used in Exception Handling in Customizing for Payment Engine under
Posting Interfaces DM Proxy [or] BCA Proxy Response .

You have defined a number range for numbering of collector and queue categories in Customizing for Payment
Engine under Clearing Maintain Number Ranges for Collectors .

Features

If a category meets the closing criteria defined in the clearing agreement, but payment items that match
the collection criteria still need to be assigned to the category, the system creates a new sequence. The
system always selects the last sequence in a category and checks the corresponding closing conditions before
assigning payment items. Each time payment items are assigned to a sequence, the system updates the total
amount and the number of payment items.

The first open sequence in a category is given the sequential number 0001. If another payment item with the
same parameter combination is collected, but the sequence is closed, for example, because it contains the
maximum number of payment items defined in the clearing agreement, the system generates a new sequence
that opens with the sequential number 0002.

The collector category number does not change until the payment transaction reconciliation date changes. A
collector category cannot be finalized if it contains open sequences. Numbering of sequences restarts at 0001
for new open collector categories or queue categories (with a new collector number and a new reconciliation
date).

You can remove payment items from queues and collectors in the following cases:

• If technical problems occur with a route and a different route has to be used, you can delete payment items
from a queue or collector.
• You can remove payment items from a queue or an open clearing collector for recall processing.
For more information, see Recall Processing [page 147].
• You can remove all payment items that are assigned to a queue or an open clearing collector from the given
queue or clearing collector.

Payment Engine (FS-PE)

Clearing Processing (FS-PE-CP) PUBLIC 359
 The system deletes the reference fields in all payment items and closes the queue or collector.

When you remove a payment item that is assigned to an open queue or an open clearing collector from the
queue or collector, the system deletes the reference fields in the payment item (collector category number,
sequence number, and payment transaction posting date) and updates the collector data, such as the number
of payment items and the current total amount.

If you remove the last payment item from an open collector, the system closes the collector.

 Note

You can remove internal payment items from open customer collectors only if the payment items have not
been assigned to a sequence.

Activities

• To assign payment items to a collector manually, on the SAP Easy Access screen, choose Payment
Engine Clearing Manage Collectors and Queues (transaction /PE1/CP_COLL).
• To assign payment items to a queue manually, on the SAP Easy Access screen, choose Payment Engine
Clearing Manage Collectors and Queues (transaction /PE1/CP_COLL).
• To assign payment items to a queue or collector automatically using a batch process, on the SAP
Easy Access screen, choose Payment Engine Periodic Processing Processes Execute Processes
(transaction /PE1/POLLER).
• To remove payment items from a queue or collector, you must determine whether:
• You want to assign payment items to a new route and a new clearing agreement manually.
• You want Payment Engine to reprocess payment items again in Routing Control and Clearing
Processing.
• Payment items are to be posted in a prior period.

More Information

Clearing Agreement [page 219]

Close Collector/Queue [page 361]

Final Processing (Collectors/Queues) [page 363]

Payment Engine (FS-PE)

360 PUBLIC Clearing Processing (FS-PE-CP)
16.5 Close Collector/Queue

Use

You use this function to close collectors and queues automatically based on the closing criteria defined in a
clearing agreement and to close collectors and queues manually.

The closing criteria for collectors are based on any of the following attributes:

• Maximum amount
• Defined time with or without a minimum amount and a minimum number of items
• Maximum number of payment items
• End-of-day processing

Payment items in a queue or collector with the status Closed are locked for processing and no more payment
items can be assigned.

The reasons you can specify for closing collectors are:

• Maximum total reached

• Maximum item number reached
• Final time reached
• Closed manually
• Time and minimum total reached
• Time and minimum item number reached
• Time, minimum total, and minimum item number reached
• Closed during end-of-day processing
• No posting-relevant items
• Maximum total reached and maximum item number reached

Integration

The system assigns payment items to a collector category or a queue category based on the collection criteria
defined in clearing agreements. If at least one of the attributes in a payment item does not match the criteria
defined for the open categories, the system generates a new collector category or queue category with a new
collector number. It then assigns the payment item to this category.

Each collector category and queue category is given a collector number based on a number range that you
define in Customizing.

The system assigns the payment items to new or existing sequences depending on the closing criteria defined
for the category in the clearing agreement. For more information, see Clearing Agreement [page 219].

Payment Engine (FS-PE)

Clearing Processing (FS-PE-CP) PUBLIC 361
Prerequisites

You have defined the closing criteria: On the SAP Easy Access screen, choose Payment Engine Master Data
Routing Control Manage Routes and Clearing Agreements (transaction /PE1/RN).

Features

You can specify the following closing conditions for a particular queue category or collector category:

• Time-based closing criteria

You can specify that collectors and queues close at different times and at different time intervals. You can
also specify the minimum closing criteria for a scheduled closing time.
• Non-time-based closing criteria
You can specify that collectors and queues close when the number of payment items reaches a maximum
item limit or a minimum amount of x currency units.

You can specify multiple closing criteria for a queue or collector. If one closing condition is met, the system
closes the queue or collector and you can no longer assign payment items to the queue or collector.

 Note

When you close queues or collectors manually, the system ignores the closing criteria defined in the
clearing agreement.

Activities

• To close collectors and queues manually, on the SAP Easy Access screen, choose Payment Engine
Clearing Manage Collectors and Queues (transaction /PE1/CP_COLL).
• To close queues or collectors that meet the closing criteria defined in the clearing agreement
automatically, on the SAP Easy Access screen, choose Payment Engine Periodic Processing
Processes Execute Processes (transaction /PE1/POLLER).

More Information

Clearing Agreement [page 219]

Assign Payment Items to Collector/Queue [page 358]

Final Processing (Collectors/Queues) [page 363]

Payment Engine (FS-PE)

362 PUBLIC Clearing Processing (FS-PE-CP)
16.6 Final Processing (Collectors/Queues)

Use

You use this function to initiate final processing of closed collector sequences. The system checks whether the
clearing agreement is locked when final processing is initiated.

Depending on the check results, the system can clear the payment items by using an alternative clearing
agreement or by processing payment items individually. If clearing is not possible, the system sends a message
with an error code to Exception Control. For more information about error handling, see Exception Control
(FS-PE-EH) [page 265].

During final processing, the system:

• Generates one or more outgoing payment orders

• Moves collected payment items to an outgoing payment order
• Sets the collector sequence to a final status

A payment order associated with a collector is set to final status if no further processing is possible (for
example, the payment order is rejected) or necessary (incoming processing is completed) in Payment Engine.
In this case, all payment items assigned to the payment order have been processed, final correspondence
has been triggered, and the payment order and clearing items have been handed over to Output Manager.
Depending on the configuration, the payment order is available for archiving.

Integration

Before you can use the Final Processing function, you use the Assign Payment Items to Collector/Queue and
Close Collector/Queue functions to process the corresponding payment items assigned to a collector or queue.

The payment items are forwarded over proxy to the account management system for posting simulation and
prenotification or for posting in the case of internal payment items. The account management system sends a
positive response (posting, posting simulation or reservation) or a negative response.

Prerequisites

• Payment items are assigned to a collector or a queue. For more information, see Assign Payment Items to
Collector/Queue [page 358].
• The collector or queue is closed. For more information, see Close Collector/Queue [page 361].
• The conditions for processing are defined in the clearing agreement. For more information, see Setting Up
Queues and Collectors [page 342].
• The clearing agreement is not locked before processing of the corresponding payment items starts. For
more information, see Clearing Agreement [page 219].
• Payment Engine is connected to an account management system. For more information, see Connection to
an Account Management System [page 166].

Payment Engine (FS-PE)

Clearing Processing (FS-PE-CP) PUBLIC 363
• You have mapped the error codes of the account management system to the error codes used in Payment
Engine and specified the relevant error ID used in Exception Handling in Customizing for Payment Engine
under Posting Interfaces DM Proxy [or] BCA Proxy Response .

Features

You can initiate final processing of a collector or a queue to generate either outgoing payment orders
or payment information in order to post payments to accounts administered by a connected account
management system.

Activities

• To initiate final processing of collectors and queues manually, on the SAP Easy Access screen, choose
Payment Engine Clearing Manage Collectors and Queues (transaction /PE1/CP_COLL).
• To initiate final processing of queues or collectors automatically, on the SAP Easy Access screen, choose
Payment Engine Periodic Processing Processes Execute Processes (transaction /PE1/POLLER).

More Information

Clearing Agreement [page 219]

Assign Payment Items to Collector/Queue [page 358]

Close Collector/Queue [page 361]

16.7 Account Management Proxy (FS-PE-AMP)

Use

You use this component to send requests to a connected account-management system (AMS). Depending on
the defined responses from the AMS, the system passes these to Exception Control for further processing in
Payment Engine.

Payment Engine (FS-PE)

364 PUBLIC Clearing Processing (FS-PE-CP)
Implementation Considerations

You need to set up and configure Account Management Proxy and a connected AMS in Customizing for
Payment Engine. You can use the proxy-interface infrastructure to connect more than one AMS. For more
information, see Connection to an Account Management System [page 166].

 Note

This documentation refers to Account Management (FS-AM) and Bank Customer Accounts (IS-B-BCA). The
tools and processes implemented in the Account Management Proxy component are designed for these
account management systems.

Any other proxy interfaces you implement derive from Account Management Proxy, but do not
automatically provide the same features, such as features for reporting. However, the basic functions are
available for all proxy interfaces.

Integration

The AM Proxy communicates with Clearing Processing, where postings and reservations are made. For more
information, see Clearing Processing (FS-PE-CP) [page 337].

Indirectly, the AM Proxy is also linked to Exception Control, where exceptions based on responses from a
connected AMS are processed. For more information, see Exception Control (FS-PE-EH) [page 265].

Features

Processing

The main processing features of Account Management Proxy (the AM Proxy) are:

• Single processing
The AM Proxy handles payment data on a payment-item by payment-item basis.
• Synchronous and asynchronous processing
The AM Proxy provides synchronous processing of payment items through open RFC connections to
the AMS. It can also use asynchronous processing, for example when the connection is temporarily not
available. You can manage asynchronous process through the Asynchronous Poller for Processing Items
report on the SAP Easy Access screen.
• Emergency scenarios
The AM Proxy is able to deal with emergency scenarios, such as:
• Handling of timeouts during posting reservation, reservation, and posting requests
• Forced posting of payment items to continue processing, even when the connection to the AMS is not
available
• Mass resubmission of payment items
• Handling of a restart after a breakdown of Payment Engine

Actions

Payment Engine (FS-PE)

Clearing Processing (FS-PE-CP) PUBLIC 365
During the clearing process, the system can call the AM Proxy to perform actions for payment items. For more
information, see:

• Posting simulation [page 366].

• Posting [page 368].
• Reservation [page 369].
• Deletion of Reservation [page 370].

Reports

Payment Engine provides the following reports for monitoring and controlling a connected SAP-specific
Account Management (FS-AM) system (AMS):

• Asynchronous Poller for Processing Items

Handles payment items waiting for asynchronous processing. This poller sends payment items to the AMS
for further processing. It provides the functions of asynchronous processing for all interactions between
Payment Engine and a connected AMS. These interactions comprise reservation, deletion of reservations,
posting simulation, and posting. You can enter ranges and schedule multiple variants for communication
with a connected AMS.
• Asynchronous Reply Poller for Items
Updates the status of items reported to be in process by a connected AMS.
• AM System Availability Monitoring
Provides information about the availability status of a connected AMS.
• Poller Job Schedule Check Report
Displays the number of payment items pending for the selected criteria.
• Buffer Monitoring Report
Provides an overview of payment items.
• PE/AM Transaction Type Consistency Report
Compares the entries in a connected AMS with the entries in Payment Engine.
• Reconciliation of PE and AM
Provides information about discrepancies between Payment Engine and a connected AMS.
• Evaluation of Outgoing Items Sent to AM System
Provides information about reconciliation with a connected AMS.

You can run these reports to perform AM Proxy tasks and other tasks from the SAP Easy Access screen. For
information about how to access these reports, see Periodic Processing [page 401].

16.7.1 Posting Simulation

Use

This function executes a posting simulation in the Account Management (AM) Proxy and performs checks in a
connected account-management system (AMS). The posting simulation determines existing locks on account
level. Depending on the setting in Customizing for Payment Engine, the AMS can perform checks such as
these:

• Account existence check

• Sufficient cover

Payment Engine (FS-PE)

366 PUBLIC Clearing Processing (FS-PE-CP)
• Account lock
• Account number (name comparison)
• Check lock

For more information, see Direct Clearing [page 357].

 Note

The AM Proxy must execute a posting simulation before the creation of a reservation on the account. If no
reservation is required, it can execute the posting simulation prior to the posting.

For more information, see Reservation [page 369] and Posting [page 368].

Prerequisites

Payment Engine is connected to an AMS through the AM Proxy.

The AM Proxy performs the posting-simulation activities based on the transaction-type configuration.

For more information, see Connection to an Account Management System [page 166].

Activities

The AM Proxy executes a posting simulation as follows:

1. On receiving an item for posting simulation, it prepares the item in the required format for the AM BAPIs.
2. It determines whether the item is processed synchronously or asynchronously (depending on the
configuration and the availability of the AMS).
3. It carries out the mapping on the basis of configuration tables.
4. It performs the posting simulation on the items individually (a retry mechanism is implemented for the
BAPI calls; the number of retries is configurable).
5. It triggers application logging.
6. It maps the results and passes the response from the AMS to Clearing Processing

More Information

Clearing Processing (FS-PE-CP) [page 337]

Exception Control (FS-PE-EH) [page 265]

Periodic Processing [page 401]

Logs [page 416]

Payment Engine (FS-PE)

Clearing Processing (FS-PE-CP) PUBLIC 367
16.7.2 Posting

Use

This function executes a posting in the Account Management (AM) Proxy and a registration of a turnover at
account level in an account-management system (AMS). The AMS performs checks that ensure successful
posting of an item. These account-level checks can be the same as for a posting simulation.

For more information, see Posting Simulation [page 366].

Postings can usually be executed within a direct clearing scenario or within a collection scenario.

For more information, see Direct Clearing [page 357] and Collector [page 346].

Prerequisites

Payment Engine is connected to an account-management system (AMS) through the Account Management
(AM) Proxy.

The checks to be carried out depend on the configuration of the transaction type in AMS.

For more information, see Connection to an Account Management System [page 166].

Activities

The AM Proxy performs posting as follows:

1. On receiving an item for posting, it prepares the item in the format required for the AM BAPIs.
2. It determines whether the item is processed synchronously or asynchronously (depending on the
configuration and the availability of the AMS).
3. It carries out the mapping on the basis of configuration tables.
4. It posts items as packages for better performance (a retry mechanism is implemented for the BAPI calls;
the number of retries is configurable).
5. It triggers application logging.
6. It maps the results, sets the status of the payment item, and passes the data Clearing Processing and to
Exception Control in case of error

More Information

Clearing Processing (FS-PE-CP) [page 337]

Exception Control (FS-PE-EH) [page 265]

Periodic Processing [page 401]

Payment Engine (FS-PE)

368 PUBLIC Clearing Processing (FS-PE-CP)
Logs [page 416]

16.7.3 Reservation

Use

This function performs a reservation in the Account Management (AM) Proxy and a preregistration of a future
turnover on account level in an account-management system (AMS) by using a prenote. A prenote is a money
reservation for a future turnover, which can comprise debit postings as well as credit postings.

Reservations can usually be executed within a direct clearing scenario or within a collection scenario.

For more information, see Direct Clearing [page 357], Collector [page 346], Assign Payment Items to
Collector/Queue [page 358], and Final Processing (Collectors/Queues) [page 363].

Prerequisites

Payment Engine is connected to an account-management system (AMS) through the Account Management
(AM) Proxy.

Reservations are based on the configuration in Customizing.

For more information, see Connection to an Account Management System [page 166].

Activities

AM Proxy performs a reservation as follows:

1. On receiving an item for reservation, it prepares the item in the format required for the AM BAPIs.
2. It determines whether the item is processed synchronously or asynchronously (depending on the
configuration and the availability of the AMS).
3. It carries out the mapping on the basis of configuration tables.
4. If a reservation request fails, the AM Proxy sends the corresponding payment items to Exception Control.
5. It triggers application logging.

More Information

Clearing Processing (FS-PE-CP) [page 337]

Exception Control (FS-PE-EH) [page 265]

Periodic Processing [page 401]

Payment Engine (FS-PE)

Clearing Processing (FS-PE-CP) PUBLIC 369
Logs [page 416]

16.7.4 Deletion of Reservation

Use

This function deletes a reservation (prenote) when Payment Engine reroutes a payment item, assigned to a
queue or to a technical queue, to a different account-management system (AMS).

For more information, see Reservation [page 369].

If necessary, the Account Management (AM) Proxy deletes the reservation (prenote) and interprets the AMS
response.

The AM Proxy can usually only delete a reservation, if an item is taken out of a queue.

Prerequisites

Payment Engine is connected to an AMS through the AM Proxy.

For more information, see Connection to an Account Management System [page 166].

Activities

The AM Proxy deletes a reservation as follows:

1. On receiving an item for delete reservation, it prepares the item in the format required for the AM BAPIs.
2. It determines whether the item is processed synchronously or asynchronously (depending on the
configuration and the availability of the AMS).
3. It deletes a reservation on the items individually (a retry mechanism is implemented for the BAPI calls; the
number of retries is configurable).
4. If a deletion request fails, the item is sent to Exception Control.
5. It triggers application logging.

More Information

Clearing Processing (FS-PE-CP) [page 337]

Exception Control (FS-PE-EH) [page 265]

Periodic Processing [page 401]

Logs [page 416]

Payment Engine (FS-PE)

370 PUBLIC Clearing Processing (FS-PE-CP)
16.8 Alternative Clearing Scenarios

Use

Alternative clearing scenarios can be activated at the clearing agreement. A reservation can be requested for
the scenario. Further processing of the transaction is handled by the output handler (converter).

Batch Booking

Batch booking is a processing option in ISO 20022. For more information, see ISO 20022 Converter. It enables
you to post individual offset transactions (ORP) per recipient (RCP). The split of the ORP item is realized in an
outgoing converter.

More Information

Batch Booking [page 124]

Payment Engine (FS-PE)

Clearing Processing (FS-PE-CP) PUBLIC 371
17 User Interface

Use

SAP Payment Engine provides different user interfaces for master data management and transaction data. The
UIs are available as Dynpro and browser-based applications (SAP Fiori apps and SAPUI5 apps).

Related Information

Payment Order [page 372]

Exception Handling [page 387]
Foreign Currency Trade Reporting [page 391]
Manage Payment Blocks [page 392]
Investigate Non-Financial Messages [page 392]
Management Cockpit [page 393]
Release [page 393]

17.1 Payment Order

For payment order management, the following UIs are available:

• Edit Payment Orders (Expert) (SAP GUI)

• Create Payment (SAP Fiori app)
• Create Payment Order (SAPUI5 app)
• Manage Payments (SAP Fiori app)
• Manage Waiting Payments (SAP Fiori app)
• Display Payment Order (SAPUI5 app)

These browser-based applications allow you to create or find payment orders or items.

Prerequisites

You have defined the layout to be applied to the specific transaction type: Each transaction type can have its
individual layout with different fields and functions.

Payment Engine (FS-PE)

372 PUBLIC User Interface
Related Information

Edit Payment Orders (Expert) [page 373]

Create Payment (SAP Fiori) [page 382]
Create Payment Order (SAPUI5) [page 384]
Manage Payments (SAP Fiori) [page 385]
Manage Waiting Payments (SAP Fiori) [page 385]
Display Payment Order (SAPUI5) [page 386]

17.1.1 Edit Payment Orders (Expert)

Use

You can use this function to display an overview of payment orders and payment items and to process payment
orders and payment items manually.

Prerequisites

• You are authorized to display the selected clearing area.

• The payment orders and payment items exist in Payment Engine.
• The payment orders and payment items have not been posted.
• You have expert experience of processing payment transactions in Payment Engine.

Features

Payment Orders

You can perform the following tasks for payment orders:

• Display existing payment orders

• Check whether payment orders are complete and correct
• Import new payment orders from a file
• Create payment orders
• Change payment orders

 Note

This function is available only for new payment orders or payment orders that require further
processing.

Payment Engine (FS-PE)

User Interface PUBLIC 373
• Reject payment orders

 Note

This function is available only for new payment orders or payment orders that require further
processing.

• Display a detailed history and messages about checks, errors, responses, update processes, and the
statuses related to a payment order during payment processing
• Display archived payment orders.

Payment Items

You can perform the following tasks for payment items:

• Search for a specific payment item in a payment order

• Switch to the previous or next payment item related to a payment order
• Check whether payment items are complete and correct
• Return payment items
This function is available only for recipient items that have not been posted.
• Redirect payment items
This function is available only for failed payment items.
• Change payment items
This function is available only for new payment items or payment items that require further processing.
• Close mandates
• Reject payment items
This function is available only for new payment items or payment items that require further processing.
• Display a detailed history and messages about the checks, errors, responses, update processes, and the
statuses related to a payment item during payment processing
• Initiate an active return.
For information, see Processing of Active Returns [page 285].

Activities

• To display, create, change, or reject payment orders and payment items, on the SAP Easy Access
screen, choose Payment Engine Payment Order Management Edit Payment Orders (Expert)
(transaction /PE1/PO_EXPERT). For more information, see:
• Payment Order and Payment Item Overview [page 375]
• Creating Payment Orders and Payment Items [page 377]
• Changing Payment Orders and Payment Items [page 380]
• Completing Mandates [page 381]
• Deleting Payment Orders and Payment Items [page 379]
• To display archived payment orders, on the SAP Easy Access screen, choose Payment Engine Payment
Order Management Edit Payment Orders (Expert) (transaction /PE1/PO_EXPERT). Choose Extras
Change Data Source Archive .
• Change documents are available when payment orders or payment items are changed. You can access
change documents by choosing Extras Change Document Payment Order or Payment Item .

Payment Engine (FS-PE)

374 PUBLIC User Interface
17.1.1.1 Payment Order and Payment Item Overview

Use

You use this function to display an overview of payment orders and payment items that you have created in
Payment Engine manually or that you have imported into Payment Engine.

Prerequisites

You have display rights for the selected clearing area.

The payment orders and payment items you want to display are in the system.

Features

The system displays all selected payment orders for a specified clearing area that match your filter criteria.

You can filter the payment orders using numerous filter criteria such as the payment order date and number, or
the account number related to the payment order.

You can select any of the payment orders or payment items from the navigation tree.

The Payment Orders and Payment Items overview screen displays detailed information about a payment order
and its payment items.

If payment items are assigned to a payment order, you can hide or show an overview of payment items and
details about individual payment items as required. In this case, the main screen is divided into the following
screen areas:

Payment Order

When you select a payment order, the top screen area displays the main attributes of the selected payment
order on different tab pages.

• Basic data
Displays information such as the status, check amounts of items and currency, processing dates, posting
date, due date, value date, and the number of items in the payment order.
• Ordering party and recipient data
Displays the main information related to the financial institutions that are sending or receiving the payment
such as the account, country, bank key, and BIC. The sender of a payment order and the ordering party
item that belongs to the payment order is usually the same financial institution.
• Exception
Displays a list of failed checks that occurred while processing the payment order. This tab page is displayed
only if a payment order contains errors. It displays the type of error, the check phase during which the error
occurred, whether Exception Control has taken control of this error, and whether a response type has been
triggered. For more information, see Exception Control (FS-PE-EH) [page 265].
This tab page is typically displayed for payment orders that require postprocessing.

Payment Engine (FS-PE)

User Interface PUBLIC 375
• Date details
Displays the most commonly used and important date fields, such as the posting date, due date, and value
date.
• File Handler
Displays original payment order data that is stored in the File Handler Database, but is not converted to
the Payment Engine metaformat because it is not required for payment processing. For more information
about the File Handler Database, see File Handler Database (FHDB) [page 297].
• References
Displays the most commonly used and important references loaded during file importing, such as a
reference to the object created in Input Manager, an external order number, the format, medium, and
channel, or references determined in payment processing, such as references to a service level agreement,
enrichment and validation check sets, or a recall.
Displays original payment order data that is stored in the File Handler Database, but is not converted to
the Payment Engine metaformat because it is not required for payment processing. For more information
about the File Handler Database, see File Handler Database (FHDB).
Displays a recall ID. You can choose the icon to display the recall screen.
Displays a check set ID to specify which payment order and cross-item checks are to be run for the
payment order during enrichment and validation. You can choose the icon to display the status of the
checks.
• Administration data
Displays the user and date and time information related to the creation, update, or release of a payment
order.

Item Overview

If payment items are assigned to the payment order, you can display the ordering party item, recipient items,
clearing item, and turnover items.

Payment Item

When you select a payment item in the Item Overview, this screen area displays the main attributes of the
selected payment item on different tab pages.

• Basic data
Displays information such as the status, amount, transaction type, and direct debit type.
• Account data
Displays information about the account, for example, the bank country, bank key, and BIC.
• Date details
Displays the most frequently used and important dates such as the posting date, the value date, and the
due date.
In the case of direct debit transactions, this tab page also displays the date by which feedback must be
received from the account management system to meet the due date.
• References
Displays the most frequently used and important references such as the payment order ID, an external
item, a collector, a previous payment item, a recall (you can choose the icon to display the recall
screen), and the unique creditor identifications (UCI) of recipient items.
This tab page also displays the mandate ID of a SEPA direct debit (SDD) when relevant.
Displays a check set ID to specify which payment item checks are to be run for the payment item during
enrichment and validation. You can choose the icon to display the status of the checks.
• Clearing information

Payment Engine (FS-PE)

376 PUBLIC User Interface
 Displays the fields related to route determination that are populated only if the system can determine a
route and a clearing agreement for the payment item during straight-through processing (STP).
• Payment remittance
You can enter remittance types here and further payment item information separately from the payment
item database table. You can use the filter function to search the list for the payment item information.
• Administration data
Displays the user and date and time information related to the creation, update or release of a payment
item.
• Exception
Displays a list of failed checks that occurred while processing the payment item. This tab page is displayed
only if a payment item contains errors. It displays the type of error, the check phase during which the error
occurred, whether Exception Control has taken control of this error, and whether a response type has been
triggered. For more information, see Exception Control (FS-PE-EH).

 Note

The system displays this tab page only when an exception has occurred, and payment items require
postprocessing.

Activities

To display this overview on the SAP Easy Access screen, choose Payment Engine Payment Order
Management Edit Payment Orders (Expert) (transaction /PE1/PO_EXPERT).

 Note

You can display an overview of status transitions for incoming and outgoing payment orders and different
payment item types in Customizing for Payment Engine (FS-PE) under Tools Functional Monitoring
Display Status Transitions .

More Information

Edit Payment Orders (Expert) [page 373]

17.1.1.2 Creating Payment Orders and Payment Items

Use

You can create payment orders and payment items manually.

Payment Engine (FS-PE)

User Interface PUBLIC 377
Prerequisites

• You have defined the settings for payment orders and payment items in Customizing for Payment Engine
under Payment Order and under Payment Items.
• You have display and edit rights for the selected clearing area.
• You have defined the release workflow in Customizing for Payment Engine under:
• Payment Order Release for Payment Order
• Payment Items Release for Payment Item

Procedure

1. On the SAP Easy Access screen, choose Payment Engine Payment Order Management Edit Payment
Order (Expert) (transaction /PE1/PO_EXPERT).
2. Select a clearing area.
The Dynamic Selection screen appears. You do not need to choose any filter options.

 Note

You can show or hide the search area and navigation tree by choosing the Switch Overview Tree On/Off
pushbutton.

3. On the Payment Orders and Payment Items overview screen, choose the Create Payment Order
pushbutton.
4. Choose a payment order type.
A payment order is created with the initial status Created Manually.
5. Switch to change mode and define the payment order attributes and save the payment order.
6. In the Edit menu, choose Payment Item Create .
7. Choose a payment item type.
A payment item is created with the initial status Created Manually.
8. Define the payment item attributes and save the payment item.

9. Choose to update the status of the payment order and each payment item and submit the payment
order and its payment items for straight-through processing (STP).
You can either flag the payment order for immediate processing or for processing at a later time.

 Note

You can also import payment orders by using File Handler.

For more information, see Input Manager [page 291] and Import File (Expert) [page 293].

More Information

Payment Order [page 133]

Payment Engine (FS-PE)

378 PUBLIC User Interface
Payment Item [page 138]

17.1.1.3 Deleting Payment Orders and Payment Items

Prerequisites

• You have display and edit rights for the selected clearing area.
• You have created the payment orders to be deleted in Payment Engine and the system has not started
processing them. You can delete a payment order that has one of the following statuses:
• Created by Input Manager
• Created Manually
• Ready for Processing

Context

You can delete payment orders and payment items imported into or created in Payment Engine before payment
processing begins.

Procedure

1. On the SAP Easy Access screen, choose Payment Engine Payment Order Management Edit Payment
Order (Expert) (transaction /PE1/PO_EXPERT).
2. Select a clearing area.

The Dynamic Selection screen appears.

3. Choose your filter options.

For more information about the available filter options, see Payment Order and Payment Item Overview
[page 375].

The system displays all payment orders for the clearing area that match the filter criteria related to the
payment order attributes.
4. From the navigation tree, double-click the payment order you want to reject.

The payment order attributes are displayed.

5. Switch to change mode.

6. Select the payment order you want to delete and choose .

Payment Engine (FS-PE)

User Interface PUBLIC 379
Results

The payment order and its related payment items are deleted from Payment Engine. The system no longer
stores the payment order and its payment items in the Payment Engine database and you can no longer
access the rejected payment order or its payment items using any transactions for payment processing or
postprocessing.

17.1.1.4 Changing Payment Orders and Payment Items

Prerequisites

• You have display and edit rights for the selected clearing area.
• The payment orders and payment items you want to change exist in Payment Engine.
• You have defined the release workflow in Customizing for Payment Engine under:
• Payment Order Release for Payment Order
• Payment Items Release for Payment Item

Context

You can manually change the attributes of payment orders and payment items that exist in Payment Engine, for
example, if a payment order contains errors.

You can change a payment order or a payment item that has one of the following statuses:

• Created Manually
• Created by Input Manager
• Ready for Processing

You can also change a payment order that is being processed but contains errors that you need to correct. You
cannot change payment orders or payment items that have any other status.

Procedure

1. On the SAP Easy Access screen, choose Payment Engine Payment Order Management Edit Payment
Orders (Expert) (transaction /PE1/PO_EXPERT).
2. Select a clearing area.

The Dynamic Selection screen appears.

Payment Engine (FS-PE)

380 PUBLIC User Interface
3. Choose your filter options.

For more information about the available filter options, see Payment Order and Payment Item Overview
[page 375].

The system displays all payment orders for the clearing area that match the filter criteria related to the
payment order attributes.
4. From the navigation tree, double-click the payment order you want to change.

The payment order attributes are displayed.

5. Switch to change mode.
6. Change the payment order attributes as required and save your changes.

7. Choose to submit the payment order and its payment items to for straight-through processing (STP).

You can either flag the payment order for immediate processing or for processing at a later time.
If the payment order contains payment items that you want to change, do the following:
8. In the Item Overview screen area, choose the payment item you want to change.

The Payment Item screen area displays the payment item attributes.
9. Switch to change mode.
10. Change the payment item attributes as required and save your changes.

11. Choose to submit the payment item to STP.

You can either flag the payment item for immediate processing or for processing at a later time.

17.1.1.5 Completing Mandates

Use

When you process incoming SEPA direct debit transactions that have been collected for a collective posting in
the account management system, you can complete the mandates once they have been used for the last time.

Prerequisites

You need to execute the following activities as appropriate in Customizing for Payment Engine (FS-PE):

• The mandate check is part of the name check in the account management system. Ensure that the name
check is not excluded by choosing Posting Interfaces DM Proxy [or] BCA Proxy Posting Maintain
Active Checks During Posting Simulation. . Ensure that the No NameCh checkbox is not selected.
• To execute a mandate check during posting simulation, activate the posting simulation for collected
payment items. Choose Payment Item Transaction Types and Transaction Type Groups Maintain and
Assign Transaction Types for Payment Items . Click the Maintenance: Transaction Types+ Control folder for
the required entry and select the Sim. Postg checkbox.
• To complete the mandate during collector posting, activate mandate completion for collected payment
items by selecting the Mand Compl checkbox in the above activity.

Payment Engine (FS-PE)

User Interface PUBLIC 381
Procedure

Mandate completion can be executed synchronously or asynchronously. To use asynchronous

processing, choose Posting Interfaces DM Proxy [or] BCA Proxy Basic Settings Maintain AM System
Communication Types in Customizing for Payment Engine (FS-PE).

From the SAP Easy Access menu, choose Payment Order Management Edit Payment Orders (Expert) and
proceed as follows:

1. Enter the required clearing area and dynamic selections.

2. Click the required ordering party item in the list of payment orders on the left.
3. Click the required payment item in the Item Overview where the status is 30 (Collected).
4. On the References tab page of the payment item, check that the system is displaying a mandate ID

5. On the Clearing Information tab page of the payment item, choose to go to the collector.
6. Make the item assignment by choosing Yes from the dialog box.
7. Close the collector.
8. Choose Final Process.: Subord. Coll from the application toolbar to check whether the mandate can be
closed.
This depends on whether checks were successful, for example, whether the mandate ID and the unique
creditor ID were included in the mandate information.
If this is the case, you can post the collector.

Result

You have now completed the mandate and posted the collector. The technical status of the payment item in the
payment order and payment item overview has changed to 34 (Assign to Order) and processing can continue.

More Information

For more information about editing payment orders, see Edit Payment Orders (Expert) [page 373].

For more information about collectors, see Collector [page 346]

17.1.2 Create Payment (SAP Fiori)

In this SAP Fiori app, you can create payments of all kinds. You can use existing templates or create new
templates.

To access this app, use transaction /UI2/FLP.

You can:

• Save a draft payment to edit it later

Payment Engine (FS-PE)

382 PUBLIC User Interface
• Add notes to a payment

Prerequisites

You have configured the SAP Fiori app as described in the Administrator's Guide for SAP Payment Engine
under Post-Installation Tasks.

Simulation

You can simulate a payment order before saving it. This means, the payment simulation runs through all the
steps (enrichment and validation, calculation of charges and fees, and routing) without actually changing the
payment order or posting data to external interfaces. At the end of the simulation, any errors and warnings that
occurred are displayed..

Related Information

Post-Installation Tasks
Determining Format/Medium/Channel by Reconciliation Units [page 383]

17.1.2.1 Determining Format/Medium/Channel by

Reconciliation Units

You can now specify at reconciliation attribute level, which format/medium/channel is to be used when
creating a payment on the User Interface.

If you have assigned reconciliation units (System ID, Application ID, Additional ID) to the converter attributes
(Format, Medium and Channel ), you can use the reconcilation units to determine the format, medium, and
channel when you create a payment using the Create Payment Order Fiori app.

To create the mapping you need to carry out the following steps:

1. Ensure that reconciliation units have been mapped to converter units ins SAP Payment Engine
Customizing ( Payment Engine Reconciliation Assign Reconciliation Units to Converter Attributes ).
2. Assign the corresponding reconciliation units to the corresponding parameter values of the Create
Payment Fiori app tile.
You do this in SAP Netweaver Customizing under SAP NetWeaver UI Technologies SAP Fiori
Configuring Launchpad Content Adding Apps to SAP Fiori Launchpad Configure Target Mappings and
Tiles .

Payment Engine (FS-PE)

User Interface PUBLIC 383
 The units correspond to the following tile parameters:

SAP Payment Engine Customizing:

Reconcilation Unit Create Payment Fiori App Parameter

System ID ReconSystem

Application ID ReconApplication

Additional ID of Reconciliation Unit ReconAdditionalId

17.1.3 Create Payment Order (SAPUI5)

Use

This browser-based SAPUI5 application allows you to create payment orders based on predefined templates or
manual settings.

 Note

This application has been reworked and is also available as an SAP Fiori app. We recommend that you use
the Create Payment SAP Fiori app. For information, see Create Payment (SAP Fiori) [page 382].

Prerequisites

The UI uses different functions to support the creation of the order object. Customizing according to the order
data is required to simplify the process.

• Define payment order and transaction types:

Order and transaction types define the main characteristics of the UI. Flag entries for manual creation
register their relation to each other in order to make them available in drop down lists.
• Define default values for attributes of the order item:
You can maintain values for attributes available on the UI as well as for technically required attributes to be
filled automatically.
• Define field routines:
The component Field Routines is applied by the UI framework. This allows for validation, data conversion
and also default value assignment based on registered development objects.

Further Functions

Due to the integrated template function, you can keep regularly used payment order data. Separate lists for
global and customer-specific templates are available. At order creation, the applicable templates become
available based on the selected payment order type. All attributes at the Create Order screen are filled
depending on the template and can be altered as needed. Once you choose Save, the order is created and

Payment Engine (FS-PE)

384 PUBLIC User Interface
automatically processed. The object ID and possible validation results are returned and become available at
the bottom of the screen.

17.1.4 Manage Payments (SAP Fiori)

In this SAP Fiori app, you can manage existing payment orders and items, as well as create new orders and
order templates.

To access this app, use transaction /UI2/FLP.

You can:

• Search for payment orders and payment items

• Recall a payment order or item
• Manage payment templates that provide only relevant fields for a specific payment type (for example, for
international transfer or internal transfer)

Prerequisites

You have configured the SAP Fiori app as described in the Administrator's Guide for SAP Payment Engine
under Post-Installation Tasks.

Related Information

Post-Installation Tasks

17.1.5 Manage Waiting Payments (SAP Fiori)

In this SAP Fiori app, you can manage payments waiting for a response from an external system.

You can set the response manually so that a payment can be further processed, for example, in case of
technical problems in the external system.

A payment can be waiting for one of the following:

• An exchange rate
• Embargo information
• A prenote from an account management system

To access this app, enter transaction /UI2/FLP.

On the Exchange Rate tab, you can set exchange rates, for example, in case of technical problems when the
exchange rate is not provided automatically.

Payment Engine (FS-PE)

User Interface PUBLIC 385
On the Embargo tab, you can define an embargo for a waiting payment item, or no embargo.

On the Account System tab, you can define the prenote response is ok or not ok.

Prerequisites

You have configured the SAP Fiori app as described in the Administrator's Guide for SAP Payment Engine
under Post-Installation Tasks.

Related Information

Post-Installation Tasks

17.1.6 Display Payment Order (SAPUI5)

This browser-based SAPUI5 application allows you to search payment orders or items based on certain
attributes and display the matching object either as a table or as a detailed screen. A quick search is integrated
into the left area of the screen to search with the direct object key (reference number).

 Note

This application has been reworked and is also available as an SAP Fiori app. We recommend that you use
the Manage Payments SAP Fiori app. For information, see Manage Payments (SAP Fiori) [page 385].

Once the search is triggered the Display area opens and presents to you a list of possible matches. The menu
at the top of the screen provides a display function including an order or item search as sub options. Each area
contains a list of possible matches and a set of attributes which you can use to filter the results. An additional
free-text search field is integrated in the upper corner of the screen.

Order Screen Filter Options

• My Orders (dropdown) filters between all orders and the orders created by you.
• Payment order type
• Creation date with predefined ranges (Today, Yesterday, Last Week, Last Month, Last Year)
• Channel
• Technical status
• Free search field

Payment Engine (FS-PE)

386 PUBLIC User Interface
Item Screen Filter Options

• My Items (dropdown) filters between all transactions and those created by you.
• Transaction type
• Creation date with predefined ranges (Today, Yesterday, Last Week, Last Month, Last Year)
• Payment item category
• Technical status
• Reference number search to find items by the external reference number

17.2 Exception Handling

For exception handling, the following UIs are available:

• Repair Payments (SAP Fiori app)

• Exception Handling (SAPUI5 app)

 Note

We recommend that you use the Repair Payments SAP Fiori app.

Related Information

Repair Payments (SAP Fiori) [page 387]

Exception Handling (SAPUI5) [page 389]

17.2.1 Repair Payments (SAP Fiori)

In this SAP Fiori app, you can repair payments that cannot be processed due to incorrect information and,
therefore, have been transferred to Exception Control.

To access this app, use transaction /UI2/FLP.

To make sure that a payment can continue to be processed, you can correct the erroneous information in the
payment, or you can trigger reactions suggested by the app, such as returning the payment to the sender.

The app displays an overview of erroneous payment orders and payment items in your assigned work basket.
You can filter the list by specific criteria.

In the exception details, you find information on how to correct the errors. For certain errors the app suggests
corrections. You can choose to correct an error or ignore it. If you ignore the error, the payment is processed
again. If the error persists, the payment is handed over to Exception Control.

Payment Engine (FS-PE)

User Interface PUBLIC 387
You can also reassign erroneous payment orders or items to another work basket.

Prerequisites

You have configured the SAP Fiori app as described in the Administrator's Guide for SAP Payment Engine
under Post-Installation Tasks.

For automatic reaction types, you have made the relevant Customizing settings for Exception Control, in
particular the definition of response types under Payment Engine Exception Control Define Response
Types .

Reserving Payment Orders and Items

You can reserve payments orders and items by doing the following:

• You branch to the detail screen of the order/item.

• You put the cursor on the line with the order/item and then click on the Set Reservation icon at the top of
the list (lock symbol).

The order/item is automatically reserved for you. The next time the screen is called up or refreshed, your user
is displayed for this order/item in the Reserved By column.

Orders/items reserved by you cannot be processed by others, unless they choose to actively remove the
reservation by using the Remove Reservation icon at the top of the list (unlock symbol).

Further Functions

You can carry out the following functions on a payment order:

• Reject the order

• Reprocess the outgoing order
• Simulate Processing
You can simulate a repaired payment order before saving it. This means, the payment simulation runs
through all the steps (enrichment and validation, calculation of charges and fees, and routing) without
actually changing the payment order or posting data to external interfaces. At the end of the simulation,
any errors and warnings that occurred are displayed.
• Carry out a Mass Update
Use this function to select all items with a particular transaction currency and/or due date in order to
perform a mass update of the following fields:
• Exchange Rate
• Due Date
You can also specify whether you want to automatically send the updated items to Repair Payments.

Payment Engine (FS-PE)

388 PUBLIC User Interface
  Note

You can only carry out a mass update on orders which have a total number of order items that does not
exceed the maximum package size.

(The maximum package size is specified in Customizing under Payment Engine Basic Settings
Global Package Settings Maintain Global Technical Package Setting .)

• Print the order

• Save as Template
Use this function to save all the details currently entered in the order, so that you can reuse them.
• Recall Order (see "Recall")
• Open PO Expert (see "Edit Payment Orders (Expert)")
• Show File Handler Data
Use this function to display an extract showing the file handler data.
• Show Original File
Use this function to display the complete file.

Related Information

Post-Installation Tasks
Recall [page 142]
Edit Payment Orders (Expert) [page 373]

17.2.2 Exception Handling (SAPUI5)

Use

The exception handling UI is a browser-based SAPUI5 application separated into an overview list and a details
screen.

 Note

This application has been reworked and is also available as an SAP Fiori app. For exception handling, we
recommend that you use the Repair Payments SAP Fiori app.

The exception handling SAPIU5 application provides the selection of automatic reaction type, for example,
Return Redirection or Order Rejects in both screens. In addition, the details screen allows you to alter the
selected business object and access the application log.

Payment Engine (FS-PE)

User Interface PUBLIC 389
Prerequisites

The same prerequisites as for the Create Order UI apply to the exception handling details screen.

For automatic reaction types, you have made the corresponding settings in Customizing for Payment Engine
under Exception Control Define Response Types .

Related Information

Repair Payments (SAP Fiori) [page 387]

Exception Control (FS-PE-EH) [page 265]

17.2.3 Manage Correction Rules (SAP Fiori)

In this SAP Fiori app, you can manage correction rules that you have either created manually, or that have been
proposed by an automatic postprocessing algorithm.

To access this app, use transaction /UI2/FLP.

You can carry out the following actions on automatically created correction rules:

• Delete a rule
• Edit a rule.
• Reserve a rule.

You can also Add a new correction rule manually.

Prerequisites

You have configured the SAP Fiori app as described in the Administrator's Guide for SAP Payment Engine
under Post-Installation Tasks.

You have made the relevant Customizing settings for correction rules as described in "Correction Rules".

Related Information

Correction Rules [page 270]

Payment Engine (FS-PE)

390 PUBLIC User Interface
17.3 Foreign Currency Trade Reporting

In this SAP Fiori app, you get an overview of the foreign currency positions and the received exchange rates
from the trading unit. On item level, you can get detailed information about the foreign payment.

Prerequisites

You have made the following settings in Customizing:

• For Payment Engine under Basic Settings Foreign Exchange

• For SAP NetWeaver under General Settings Currencies
You have configured the SAP Fiori app as described in the Administrator's Guide for SAP Payment Engine
under Post-Installation Tasks.

The foreign currency positions are sent to the trading unit in packages. The trading unit provides the exchanges
rates. This app shows the packages and the exchange rates that the trading unit has provided.

To access this app, enter transaction /UI2/FLP.

You can:

• Close a trade report to send it to the trading unit by choosing Report Now for All.
• Enter an exchange rate to process payments waiting for the exchange rate, for example, in case of technical
problems when the exchange rates cannot be received automatically. The exchange rate you have entered
applies for all waiting payments of this currency.
• Create a new foreign currency posting if items still missing at this time. The package is then created
automatically if no existing package is open.
• Add foreign currency transactions manually to purchase or sell foreign currencies or create a cross-
currency payment.

Depending on your Customizing settings for Payment Engine under Basic Settings Foreign Exchange ,
transfer to trading is performed in one of the following ways:

• Foreign currency transactions are collected for each currency and day and then transferred to the trading
unit in bulk at regular intervals.

 Note

The trade report is not closed until the background job is executed. All positions collected up to that
time are included in the transfer to trading.

• Single transactions are directly sent to the trading unit.

Related Information

Post-Installation Tasks
Foreign Exchange (Overview) [page 122]

Payment Engine (FS-PE)

User Interface PUBLIC 391
17.4 Manage Payment Blocks

In this SAP Fiori app, you can display, create, edit, and delete payment blocks for currencies, banks, and
countries. A payment block prevents payments from being processed.

To access this app, use transaction /UI2/FLP.

Prerequisites

You have configured the Fiori app as described in the Administrator's Guide for SAP Payment Engine under
Post-Installation Tasks.

Related Information

Post-Installation Tasks

17.5 Investigate Non-Financial Messages

Use

The user interface (UI) allows the management of non-financial messages, for example, SWIFT MTnXX
messages.You can investigate incoming messages and create responses or new requests.

Prerequisites

In order to display, edit and create non-financial messages, it is necessary to maintain converter Customizing
for Payment Engine for the corresponding message under:

File Handler Basic Settings Define Formats

File Handler Basic Settings Define Media

File Handler Basic Settings Define Channels

File Handler Basic Settings Maintain Converter

File Handler SWIFT Format Converter Maintain Order Creation for Non-Financial Messages

File Handler XML Converter Define Converter Implementation for Format Converter

Payment Engine (FS-PE)

392 PUBLIC User Interface
Features

You can display incoming non-financial messages as well as creating new outgoing messages. The message
content is displayed both in a field view and an XML view. Furthermore, you can search for related business
objects (for example, payment orders) of which attributes can be mapped into the currently created message.

The program provides sections to display the main attributes for these related objects. In addition to the
default XML view, you can replace all screen sections with customer-specific variants. Each converter needs to
be enabled for the UI framework and provides screen elements for header data and message details

Example

You can use the program to track incoming query messages (SWIFT MT195) and create corresponding
responses (SWIFT MT196). For more information about converters, see SWIFT Converter [page 302].

17.6 Management Cockpit

You use this web application to display the available data of the information system. For more information, see
Information System (FS-PE-IS) [page 440].

It provides an overview of monitoring data and reconciliation details. You can customize the user interface
to your needs. The system provides a standard chart for functional monitoring data that is adjustable. The
available components are repeatable, which allows you to use different charts of function data next to each
other for a proper overview.

For more information, see tansaction /PE1/COCKPIT.

17.7 Release

In the My Inbox SAP Fiori app, you can release transaction data objects, such as payment orders or items, and
master data objects, such as service level agreements or payment blocks.

This app is based on the standard My Inbox SAP Fiori app. For more information, search for My Inbox on
https://help.sap.com.

There are two variants to the app:

• The master / detail variant

• The expert mode variant

To access this app, enter transaction/UI2/FLP.

Payment Engine (FS-PE)

User Interface PUBLIC 393
The following detail views are available for the app:

• Order view
• Order item view

 Note

Other release objects, such as SLA release objects, or clearing agreement release objects etc.should be
released in the backend workflow. You can, however, choose to release them in the app (without a detail
view).

Prerequisites

You have configured the Fiori app as described in the Administrator's Guide for SAP Payment Engine under
Post-Installation Tasks.

Reserving Tasks

You can reserve tasks by doing the following:

• In the master / detail app variant, click on the task that you want to reserve and then click on Claim.
• For the expert mode variant, you can specify in the configuration of the tile (in the launchpad), that a task is
automatically reserved as soon as a user opens the work item detail screen.

 Note

To activate this function, set the parameter autoClaim=true for the expert mode tile.

Tasks that are reserved by you are not displayed in other users' work lists.

Related Information

Post-Installation Tasks

Payment Engine (FS-PE)

394 PUBLIC User Interface
17.7.1 Setting up Additional Search Criteria for Orders and
Items

Context

For the SAP Fiori app My Inbox you can add additional search criteria in expert mode at order and at item level,
which can be used as criteria to filter orders and items within the app.

To set up additional criteria, carry out the following steps:

Procedure

1. Call up transation SE38 and enter program RSWD_MAINTAIN_USER_ATTR (Create and Maintain User
Attributes).
2. Enter the following data and then choose Execute.
• Customizing: X
• Scenario Filter : WF_INBOX_DC
3. Choose Create New Entry. Enter the details for the filter criterion that you wish to add.

For sample entries, see SAP Fiori App My Inbox: Sample Data for Additional Filter Criteria.
4. Save your entries.

Related Information

SAP Fiori App My Inbox: Sample Data for Additional Filter Criteria [page 396]

Payment Engine (FS-PE)

User Interface PUBLIC 395
17.7.1.1 SAP Fiori App My Inbox: Sample Data for Additional
Filter Criteria

You can can define additional fields for filtering orders and items in the SAP Fiori app MyInbox in expert mode.

Using, for example, Task TS77408247, you can create the following entries:

Name Description Expression Type

/SWL/ALL/DYNCO10 Value Date %/PE1/ D

CL_FIORI_INBOX_DYN_ATT
RS.GET_DYN_ATTR_VALUE_
BY_OBJ(OBJECT=&_WI_OBJ
ECT_ID&
FIELD_NAME='VALUE_DATE
')%

/SWL/ALL/DYNCO11 Country %/PE1/ C

CL_FIORI_INBOX_DYN_ATT
RS.GET_DYN_ATTR_VALUE_
BY_OBJ(OBJECT=&_WI_OBJ
ECT_ID&
FIELD_NAME='COUNTRY')%

/SWL/ALL/DYNCO12 Create Date %/PE1/ D

CL_FIORI_INBOX_DYN_ATT
RS.GET_DYN_ATTR_VALUE_
BY_OBJ(OBJECT=&_WI_OBJ
ECT_ID&
FIELD_NAME='CRDAT')%

/SWL/ALL/DYNCO13 Execution Date %/PE1/ D

CL_FIORI_INBOX_DYN_ATT
RS.GET_DYN_ATTR_VALUE_
BY_OBJ(OBJECT=&_WI_OBJ
ECT_ID&
FIELD_NAME='PL_PROC_DA
TE')%

/SWL/ALL/DYNCO14 Sender BIC %/PE1/ C

CL_FIORI_INBOX_DYN_ATT
RS.GET_DYN_ATTR_VALUE_
BY_OBJ(OBJECT=&_WI_OBJ
ECT_ID&
FIELD_NAME='SND_EXT_BI
C')%

Payment Engine (FS-PE)

396 PUBLIC User Interface
Name Description Expression Type

/SWL/ALL/DYNCO15 Priority %/PE1/ C

CL_FIORI_INBOX_DYN_ATT
RS.GET_DYN_ATTR_VALUE_
BY_OBJ(OBJECT=&_WI_OBJ
ECT_ID&
FIELD_NAME='PRIORITY')
%

T/SWL/ALL/DYNCO16 Risk Score %/PE1/ I

CL_FIORI_INBOX_DYN_ATT
RS.GET_DYN_ATTR_VALUE_
BY_OBJ(OBJECT=&_WI_OBJ
ECT_ID&
FIELD_NAME='RISK_SCORE
')%

/SWL/ALL/DYNCO17 Work Basket %/PE1/ C

CL_FIORI_INBOX_DYN_ATT
RS.GET_DYN_ATTR_VALUE_
BY_OBJ(OBJECT=&_WI_OBJ
ECT_ID&
FIELD_NAME='WORK_BASKE
T_ID')%

/SWL/ALL/DYNCO18 ORP Account Number %/PE1/ C

CL_FIORI_INBOX_DYN_ATT
RS.GET_DYN_ATTR_VALUE_
BY_OBJ(OBJECT=&_WI_OBJ
ECT_ID&
FIELD_NAME='WORK_BASKE
T_ID')%

T/SWL/ALL/DYNCO19 Clearing Area %/PE1/ C

CL_FIORI_INBOX_DYN_ATT
RS.GET_DYN_ATTR_VALUE_
BY_OBJ(OBJECT=&_WI_OBJ
ECT_ID&
FIELD_NAME='CLEARING_A
REA')%

/SWL/ALL/DYNCO20 Change User %/PE1/ C

CL_FIORI_INBOX_DYN_ATT
RS.GET_DYN_ATTR_VALUE_
BY_OBJ(OBJECT=&_WI_OBJ
ECT_ID&
FIELD_NAME='CHUSR')%

Payment Engine (FS-PE)

User Interface PUBLIC 397
Name Description Expression Type

/SWL/ALL/DYNCO21 Transaction Amount %/PE1/ F

CL_FIORI_INBOX_DYN_ATT
RS.GET_DYN_ATTR_VALUE_
BY_OBJ(OBJECT=&_WI_OBJ
ECT_ID&
FIELD_NAME='TR_AMOUNT'
)%

/SWL/ALL/DYNCO22 Sum of Amounts %/PE1/ F

CL_FIORI_INBOX_DYN_ATT
RS.GET_DYN_ATTR_VALUE_
BY_OBJ(OBJECT=&_WI_OBJ
ECT_ID&
FIELD_NAME='SUM_ITEMS'
)%

/SWL/ALL/DYNCO23 Sum Currency %/PE1/ F

CL_FIORI_INBOX_DYN_ATT
RS.GET_DYN_ATTR_VALUE_
BY_OBJ(OBJECT=&_WI_OBJ
ECT_ID&
FIELD_NAME='SUM_CURR')
%

/SWL/ALL/DYNCO24 Release Activity %/PE1/ C

CL_FIORI_INBOX_DYN_ATT
RS.GET_DYN_ATTR_VALUE_
BY_OBJ(OBJECT=&_WI_OBJ
ECT_ID&
FIELD_NAME='SUM_CURR')
%

/SWL/ALL/DYNCO25 IBAN ORP at PO %/PE1/ C

CL_FIORI_INBOX_DYN_ATT
RS.GET_DYN_ATTR_VALUE_
BY_OBJ(OBJECT=&_WI_OBJ
ECT_ID&
FIELD_NAME='SUM_CURR')
%

/SWL/ALL/DYNCO26 Acct No. or IBAN %/PE1/ C

ORP CL_FIORI_INBOX_DYN_ATT
RS.PI_ACCT_NO_OR_IBAN_
ORP(OBJECT=&_WI_OBJECT
_ID& FIELD_NAME='')%

Payment Engine (FS-PE)

398 PUBLIC User Interface
Name Description Expression Type

/SWL/ALL/DYNCO27 Acct No. or IBAN %/PE1/ C

RCP CL_FIORI_INBOX_DYN_ATT
RS.PI_ACCT_NO_OR_IBAN_
RCP(OBJECT=&_WI_OBJECT
_ID& FIELD_NAME='')%

/SWL/ALL/DYNCOL1 Trans. Type %/PE1/ C

CL_FIORI_INBOX_DYN_ATT
RS.GET_DYN_ATTR_VALUE_
BY_OBJ(OBJECT=&_WI_OBJ
ECT_ID&
FIELD_NAME='TRANS_TYPE
')%

/SWL/ALL/DYNCOL2 Tech. Status %/PE1/ C

CL_FIORI_INBOX_DYN_ATT
RS.GET_DYN_ATTR_VALUE_
BY_OBJ(OBJECT=&_WI_OBJ
ECT_ID&
FIELD_NAME='TECH_STAT'
)%

/SWL/ALL/DYNCOL3 PO Type %/PE1/ C

CL_FIORI_INBOX_DYN_ATT
RS.GET_DYN_ATTR_VALUE_
BY_OBJ(OBJECT=&_WI_OBJ
ECT_ID&
FIELD_NAME='PO_TYPE')%

/SWL/ALL/DYNCOL4 Order Number %/PE1/ C

CL_FIORI_INBOX_DYN_ATT
RS.GET_DYN_ATTR_VALUE_
BY_OBJ(OBJECT=&_WI_OBJ
ECT_ID&
FIELD_NAME='PO_NO')%

/SWL/ALL/DYNCOL5 Item Number %/PE1/ C

CL_FIORI_INBOX_DYN_ATT
RS.GET_DYN_ATTR_VALUE_
BY_OBJ(OBJECT=&_WI_OBJ
ECT_ID&
FIELD_NAME='PI_NO')%

Payment Engine (FS-PE)

User Interface PUBLIC 399
Name Description Expression Type

/SWL/ALL/DYNCOL6 Format %/PE1/ C

CL_FIORI_INBOX_DYN_ATT
RS.GET_DYN_ATTR_VALUE_
BY_OBJ(OBJECT=&_WI_OBJ
ECT_ID&
FIELD_NAME='IN_OUT_FOR
MAT')%

/SWL/ALL/DYNCOL7 Medium %/PE1/ C

CL_FIORI_INBOX_DYN_ATT
RS.GET_DYN_ATTR_VALUE_
BY_OBJ(OBJECT=&_WI_OBJ
ECT_ID&
FIELD_NAME='MEDIUM')%

/SWL/ALL/DYNCOL8 Channel %/PE1/ C

CL_FIORI_INBOX_DYN_ATT
RS.GET_DYN_ATTR_VALUE_
BY_OBJ(OBJECT=&_WI_OBJ
ECT_ID&
FIELD_NAME='CHANGE')%

/SWL/ALL/DYNCOL4 Transaction %/PE1/ C

Currency CL_FIORI_INBOX_DYN_ATT
RS.GET_DYN_ATTR_VALUE_
BY_OBJ(OBJECT=&_WI_OBJ
ECT_ID&
FIELD_NAME='TR_CURR')%

Payment Engine (FS-PE)

400 PUBLIC User Interface
18 Periodic Processing

Use

You use certain reports and functions in Payment Engine to perform tasks on a specific date in a defined time
cycle. These reports are grouped under periodic processing.

Some applications give you the option of parallel processing, thus improving performance. You can use the
Customizing settings to control the number and distribution of the tasks or jobs running in parallel on a specific
server and the maximum number of processes permitted for parallel processing.

Prerequisites

You have defined the settings related to performance in Customizing for Payment Engine under Tools
Performance .

Features

You can run the following reports on the SAP Easy Access screen, by choosing Payment Engine Periodic
Processing .

Processes

Report Transaction

Execute Processes /PE1/POLLER

Resubmission of Orders and Items /PE1/RESUB

Finalize Incoming Payment Orders /PE1/CORR_BP02

Reject Pending Payment Orders /PE1/REJECT_PEND_PO

Resubmission of Outgoing Orders /PE1/RST_OUT_ORD

Multi-Collection /PE1/R_MULTI_COLLECT

Process Items Matching Recall Automatically /PE1/RECALL_AUTO

Communication with an Account Management System

Payment Engine (FS-PE)

Periodic Processing PUBLIC 401
Report Transaction

Asynchronous Poller for Processing Items /PE1/WRAP_POLLER

Asynchronous Reply Poller for Items /PE1/REPLY_POLLER

For more information, see Account Management Proxy (FS-PE-AMP) [page 364] and Connection to an Account
Management System [page 166].

Information System

Report Transaction

AM System Availability Monitoring /PE1/AM_STATUS

PE/AM Transaction Type Consistency Report /PE1/PSAM_TTYPES_CON

Poller Job Schedule Check Report /PE1/JOB_SCHED_CHECK

Buffer Monitoring Report /PE1/BUF_MON

End-of-Day Processing

Report Transaction

Set Day/End-of-Day Processing /PE1/EOD_SET_DATE

Execute Accrual Process /PE1/ACCRUAL

Increase Dates in Parallel Processing /PE1/DATE_INCR

Update Status of Items for Future Posting /PE1/PIZ_UPDATER

For more information, see End-of-Day Processing (FS-PE-EOD) [page 403] and Accrual [page 405].

Reconciliation

Report Transaction

Evaluation of Incoming Items /PE1/RCN_INP

Evaluation of Outgoing Items /PE1/RCN_OUTP

Evaluation of Outgoing Items Sent to AM System /PE1/RCN_AM_AREA

For more information, see Reconciliation [page 407].

Correspondence

Payment Engine (FS-PE)

402 PUBLIC Periodic Processing
Report Transaction

Start Correspondence Printing /PE1/PRINT_CORR

Display Correspondence /PE1/ERROR_CORR

For more information, see Correspondence (FS-PE-COR) [page 410].

18.1 End-of-Day Processing (FS-PE-EOD)

Use

You use this component to complete processing on a given business day in accordance with correct
organizational and accounting practices and to ensure that a posting day is closed correctly in synchronization
with connected account management systems so that reconciliation can take place.

End-of-day processing is performed for each clearing area, that is, if more than one account management
system is linked to each clearing area, end-of-day processing is performed for each clearing area and not for
each account management system.

Implementation Considerations

You can execute End-of-Day Processing functions by means of an external job scheduler or manually. The
process control of End-of-Day Processing is not included in the Payment Engine functionality. You must
implement a background job scheduler for job controlling to manage communication of the involved systems.

Integration

The End-of-Day Processing component uses data from feeder and forwarding systems, from account
management systems, and from the Clearing Processing component.

Features

The main functions supported by End-of-Day Processing are accrual and reconciliation. For more information,
see Accrual [page 405] and Reconciliation [page 407].

Payment Engine (FS-PE)

Periodic Processing PUBLIC 403
More Information

Process Flow of End-of-Day Processing [page 404]

Connection to an Account Management System [page 166]

18.1.1 Process Flow of End-of-Day Processing

Use

You use this process to complete processing of payment transactions on a given business day.

Process

 Note

If you use a background job scheduler, at the beginning of the process, the background job scheduler sends
a message to the system that triggers end-of-day processing. When end-of-day processing is completed,
the system notifies the background job scheduler by sending a message.

If you complete processing of payment transactions manually, you perform the following steps:

1. You increase the reconciliation date: The system sets the reconciliation date to the next business day.

 Note

This step ensures that any new payment orders submitted to Payment Engine are not processed
until the next bank workday. The system sets the status of these new payment orders to Ready for
Processing.

2. You process all payment orders that do not have a final status with a reconciliation date that is either
the current date or earlier than the current date (earlier than the time at which you initiated end-of-day
processing).
3. You close open collectors and queues for which the end of the day is defined as the closing criteria and
initiate final processing of these collectors and queues. For more information, see Close Collector/Queue
[page 361] and Final Processing (Collectors/Queues) [page 363].

 Note

You define closing criteria for collectors and queues in the clearing agreement. For more information,
see Clearing Agreement [page 219].

4. You create reconciliation evaluation reports. For more information, see Reconciliation [page 407].
5. You create a report of any discrepancies between Payment Engine and an account management (AM)
system.
6. You execute the accrual process. The system accrues all nonprocessed payment items from payment
orders that have been processed only on one side. For more information, see Accrual [page 405].

Payment Engine (FS-PE)

404 PUBLIC Periodic Processing
7. You process all accrual orders.
If new open collectors or queues result from the accrual orders processing, you must repeat step 4 to
process and perform final processing of these collectors and queues.
8. You create reconciliation evaluation reports (see step 4).
You repeat this step to allow for adjustments performed during the accrual process.
9. You create a report of any discrepancies between Payment Engine and an account management (AM)
system (see step 5).
You repeat this step to allow for adjustments performed during the accrual process.
10. You increase the reconciliation date of all payment items that have not been finally processed.

18.1.2 Accrual

Use

You use this process to create accrual orders for posting to an account management system in order to
balance the general ledger at the end of the day.

The accrual process considers all payment orders that are not finally processed, but contain at least one
ordering party item that has been posted to an account management system. The amount that is missing
in the account management system (because the payment order contains posted and nonposted payment
items) is posted to the account management system for the current reconciliation day.

Prerequisites

• You have defined and maintained transaction type symbols for accrual in Customizing for Payment Engine
under Clearing Define and Maintain Transaction Type Symbols .
• You have defined the settings for accrual in Customizing for Payment Engine under Accrual by performing
the following Customizing activities:
• Define Accrual Types
• Define Accrual Accounts for Accrual Types
• Assign an Accrual Processing Type
• Map Accrual Types and Item Statuses
• Assign Transaction Types for Accrual

Process

The accrual process takes place during end-of-day processing after the reconciliation date has been set to the
next business day and before the posting date in the account management system and the final reconciliation
date have been increased. For more information about end-of-day processing, see Process Flow of End-of-Day
Processing [page 404].

Payment Engine (FS-PE)

Periodic Processing PUBLIC 405
1. You increase the reconciliation date: The system sets the reconciliation date to the next business day.

 Example

The reconciliation date is increased from April 6, 2009 to April 7, 2009.

2. The system determines which payment items in Payment Engine were only posted on one side, that is,
were not posted on an account in an account management system, but the corresponding ordering party
was already posted in an account management system.

 Example

Ten payment items with the posting date April 6, 2009 are assigned to a collector that is not yet closed.

3. The system groups payment items that need to be accrued by accrual types that are defined in
Customizing, for example, Queues and Collectors, Pending, or Recalls. Each accrual type is mapped to
a possible technical status of payment items.

 Example

The ten payment items are grouped in the accrual type Queues and Collectors.

4. The system creates accrual orders for the payment items that are to be accrued.
The number of accrual orders created depends on the processing category. The processing categories are:
• Collective processing
The system creates up to four accrual orders based on the transaction type (debit or credit) and the
posting type (internal or external) for each accrual category and for each accrual account.

 Example

The accrual order created for the ten payment items contains the posting for the payment items
and an offsetting posting with the reconciliation date as the posting date, for example, April 7,
2009. Consequently, the accrual order consists of one ordering party item and one recipient item
with the amount of all ten payment items.

• Single-item processing
The system creates an accrual order for each payment item that is to be accrued.

 Note

An accrual order is a Payment Engine-internal payment order type. Each accrual order contains a
reference to the original payment order.

5. You submit the accrual order to straight-through-processing for final processing. For more information, see
End-to-End Payment Processing [page 98].
6. The system transfers the payment items in the accrual order to the account management system over the
AM Proxy and the amount is posted to an accrual account.
The system uses the account managing area to determine the accrual account to which payment items in
an accrual order are posted.
7. You increase the final reconciliation date of the accrued payment items.

 Example

The final reconciliation date is increased from April 6, 2009 to April 7, 2009.

Payment Engine (FS-PE)

406 PUBLIC Periodic Processing
8. If the payment items that have been processed remain in Payment Engine for several days, the nonposted
payment items are accrued until they have been posted on an account.

 Example

The ten payment items are also not posted on an account the following day because the collector
has not met the defined closing criteria. These payment items are accrued on every day on which the
collector remains open.

More Information

Account Management Proxy (FS-PE-AMP) [page 364]

18.1.3 Reconciliation

Use

This function enables you to generate reconciliation data and to perform automatic reconciliation with an
account management system. Reconciliation data consists of payment item information that the system stores
during processing. You can use this data to identify and reconcile discrepancies during end-of-day processing.

Integration

Reconciliation data is based on incoming payment information, information sent to account management
systems, outgoing payment information, internally created data, and information related to nonfinalized
payment items. Therefore, this function has dependencies with the following components:

• File Handler (for Input Manager and Output Manager)

For more information, see File Handler (FS-PE-FH) [page 289].
• Clearing Processing
For more information, see Clearing Processing (FS-PE-CP) [page 337].
• Account Management Proxy
For more information, see Account Management Proxy (FS-PE-AMP) [page 364].

Prerequisites

• You have defined clearing areas in Customizing for Payment Engine by choosing Basic Settings
Organization Define Clearing Area .

Payment Engine (FS-PE)

Periodic Processing PUBLIC 407
• You have defined reconciliation settings in Customizing for Payment Engine under Reconciliation by
performing the following Customizing activities:
• Define Reconciliation Settings for Clearing Areas
• Assign Reconciliation Units to Converter Attributes
• Define Reconciliation Groups
• Map Reconciliation Groups and Technical Statuses
• To perform automatic reconciliation with an account management system, you have defined the settings
in Customizing for Payment Engine by choosing Reconciliation Business Add-Ins (BAdIs) BAdI:
Configuration of Reconciliation Screens .
• If you want to use the DataSources, do the following:
• Compress the reconciliation data using transaction/PE1/COMP_RECON_DATA.
The system then changes the status of any affected entries in table /PE1/DB_RECONC to status A
(aggregated). Only entries with this status are extracted by means of the Payment Engine extractors.

Features

• Grouping of payment item information based on:

• Clearing area
• Reconciliation date
• Reconciliation unit (system ID, application ID, additional ID)

 Note

Reconciliation units make it easier to evaluate reconciliation values. For example, if a reconciliation
report for incoming payment items shows discrepancies in the information provided by a particular
application such as a feeder system, you only need to evaluate payment items for a certain
reconciliation unit.

• Reconciliation status
Represents the processing status of a payment item at the time of reconciliation
• Payment item type
• Transaction type (debit or credit)
• Transaction currency
• Account managing area
• Posting date
• Generation of reconciliation data for payment items based on reconciliation categories that
correspond to the different actions performed on payment items.
• Incoming payment items
Payment items submitted to Payment Engine by means of Input Manager or over the payment order
interface and payment items created manually
• Outgoing payment items
Payment items forwarded to an external system by Output Manager for conversion
• Outgoing payment items transferred to an account management system

Payment Engine (FS-PE)

408 PUBLIC Periodic Processing
• Grouping of payment orders based on:
• Clearing area
• Reconciliation date
• Reconciliation unit (system ID, application ID, additional ID)
• Reconciliation status
Represents the processing status of a payment item at the time of reconciliation
• Transaction type (debit or credit)
• Transaction currency
• Account managing area
• Generation of accumulated sums (number of payment items/payment orders and sum of payment item/
payment orders amounts) based on the groupings listed above.
• Automatic reconciliation with an account management system
You can perform reconciliation for payment items that are relevant only for the account managements
systems of the respective clearing area. You can display the payment item information available in Payment
Engine and the payment item information transferred from a connected account management system.
You can use this function to compare the number of payment items and the sum of the payment items for
a reconciliation unit in both Payment Engine and in an account management system.
If the status of a payment item in the account management system is functionally different from the status
in Payment Engine, you can display discrepancies and perform manual reconciliation with the relevant
account management system.

 Note

We recommend that you perform reconciliation with an account management system daily during
end-of-day processing (transaction /PE1/EOD_SET_DATE) . You can run this report at other times;
however, you must first run the reconciliation evaluation reports because the automatic reconciliation
report reads only aggregated reconciliation sums.

Data Sources

The following DataSources are available for the extraction of flow data into the BI system and are part of the
reconciliation hub concept

Name Description

0PE_RH_PAYMORDER_AGGR_TRAN Reconciliation Hub: Payment Order Aggregated Data

Extractor

0PE_RH_PAYMORDER_DETL_TRAN Reconciliation Hub: Payment Order Detailed Data Extractor

0PE_RH_PAYMITEM_AGGR_TRAN Reconciliation Hub: Payment Item Aggregated Data Extractor

0PE_RH_PAYMITEM_DETL_TRAN Reconciliation Hub: Payment Item Detailed Data Extractor

For information about these DataSources, see DataSources in SAP Payment Engine [page 442].

Payment Engine (FS-PE)

Periodic Processing PUBLIC 409
Activities

To evaluate payment items for reconciliation purposes on the SAP Easy Access screen, choose Payment
Engine Periodic Processing End-of-Day Processing Reconciliation and one of the following:

• Evaluation of Outgoing Items Sent to AM System (transaction /PE1/RCN_AM_AREA)

• Evaluation of Incoming Items (transaction /PE1/RCN_INP)
• Evaluation of Outgoing Items (transaction /PE1/RCN_OUTP)

More Information

Process Flow of End-of-Day Processing [page 404]

Connection to an Account Management System [page 166]

18.2 Correspondence (FS-PE-COR)

Use

You use this component to create correspondence, display correspondence, and forward correspondence to an
output management system (OMS). The OMS then formats the generated documents and distributes them to
the define target media, such as a department printer, a fax server, or a mail server.

Prerequisites

You have made the settings in Customizing for Payment Engine under Cross-Application Components
General Application Functions Correspondence .

Features

You can create and forward synchronous and asynchronous correspondence information. If you create
asynchronous correspondence, the system sends information to a table and creates the correspondence
during end-of-day processing. The system creates synchronous correspondence immediately.

You can trigger the creation of correspondence for payment orders and payment items. The trigger depends on
the correspondence type:

• Some correspondence types are created when the payment is forwarded to exception handling based on
response types. For more information, see Exception Control (FS-PE-EH) [page 265]. For example, you can

Payment Engine (FS-PE)

410 PUBLIC Periodic Processing
 create correspondence for different recall types. The system distinguishes between customer recalls and
bank recalls. For more information, see Recall Management [page 144].
• For some correspondence types, correspondence is triggered depending on the SLA settings. You can also
block all correspondence types at SLA level.
• Some correspondence types are triggered by the status of the order or item.

In addition, code words and SLA settings trigger correspondence if a specific event is reached in the process.

You can define the settings for correspondence in active service level agreements. You can:

• Define the delivery method (by fax, e-mail, or as a list).

• Create correspondence during clearing and settlement for payment orders that have reached their final
status and for payment items that cannot be processed. For more information about final processing, see
Clearing Processing (FS-PE-CP) [page 337].
• Determine whether correspondence is necessary during enrichment and validation. For more information,
see Enrichment and Validation [page 311].
• Create correspondence for SEPA payment transactions.

More Information

Start Correspondence Printing [page 411]

Display Correspondence [page 414]

Service Level Agreement [page 256]

18.2.1 Start Correspondence Printing

Use

You use this report to start the asynchronous creation of correspondence. You run this report typically during
end-of-day processing.

Integration

You can include the report in end-of-day processing by using job nets. For more information, see SAP Library
under Setting Up and Starting Job Nets. For more information about end-of-day processing, see End-of-Day
Processing (FS-PE-EOD) [page 403].

You can also start the report from external job administration by using the SAP XBP interface. For information
about the eXternal Interface for Background Processing (XBP), see http://www.sdn.sap.com/irj/sdn by
choosing SAP NetWeaver Capabilities Lifecycle Management Operations Central Process Scheduling .

Payment Engine (FS-PE)

Periodic Processing PUBLIC 411
Prerequisites

Define Communication Types

If you want to include the report in end-of-day processing by using job nets, you define job nets in Customizing
for Cross-Application Components by choosing General Application Functions Parallel Processing and Job
Control Define Job Nets .

 Note

To use synchronous creation of correspondence, you can use the Business Add-In BAdI: Implementation
of User Methods for Synchronous Correspondence in Customizing for Payment Engine by choosing
Payment Order Business Add-Ins (BAdIs) BAdI: Implementation of User Methods for Synch.
Corresp .

Define Correspondence Types

You have checked that the correspondence types you require are defined in Customizing for Cross-Application
Components by choosing General Application Functions Correspondence Define Correspondence
Types .

Assign Correspondence Types to Response Types

• You have assigned correspondence types to response types for further processing for payment items and
payment orders in Customizing for Payment Engine by choosing Exception Control Define Response
Types General Response Types Define Response Types for Further Processing .
• You have assigned correspondence types to the response types for reversed payment orders in
Customizing for Payment Engine by choosing Exception Control Define Response Types Response
Types: Payment Order Define Response Types for Reversal/Rejection .
• You have assigned correspondence types to the response types for payment orders and payment items
that need resubmitting in Customizing for Payment Engine by choosing Exception Control Define
Response Types :
• Response Types: Payment Order Define Response Types for Postprocessing
• Response Types: Payment Item Define Response Types for Postprocessing
• You have assigned correspondence types to the response types for the authorization of payment orders
and payment items that have been sent to Exception Control in Customizing for Payment Engine by
choosing Exception Control Define Response Types :
• Response Types: Payment Order Maintain Responses for Payment Order Authorization
• Response Types: Payment Item Maintain Responses for Payment Item Authorization
• You have assigned correspondence types to the response types for rerouting payment items in
Customizing for Payment Engine by choosing Exception Control Define Response Types Response
Types: Payment Item Maintain Response Type for Reroute Transaction Type .

Define Settings in Service Level Agreements

You have managed the settings for correspondence in the service level agreement. On the SAP Easy
Access screen, choose Payment Engine Master Data Service Level Agreements Manage Service Level
Agreements (transaction /PE1/SLA). For more information, see Service Level Agreement [page 256].

Payment Engine (FS-PE)

412 PUBLIC Periodic Processing
Define the Correspondence Layout

You have defined the settings for Print Workbench in Customizing for Cross-Application Components under
General Application Functions Print Workbench .

Features

The system provides a list of defined correspondence types, such as a non-execution confirmation or a
processing confirmation. You can select the correspondence types you want to print and define the print
parameters.

Selection

Selection parameters for correspondence requests

• Clearing area
• Correspondence type
• Date ID

Print parameters

You can define the following print parameters:

• Documentation transmission method, for example, print

• SAPscript format
• SmartForm output format
• Output format of PDF form
• Output device
• Archiving mode
• Indicate whether an output request is automatically created in the spool after the last document in a print
run
• Indicate whether the system creates a new spool ID for each package
• Print mode
• Print
• Test print
• Repeat print

File select

• Local file
• Log file name

Technical parameters

• Number of correspondence documents created for each package

Output

The report generates a printout of the selected correspondence as a print, test print, or repeat print. If you
choose Print Parameters, the report generates a printout of the defined print parameters.

Payment Engine (FS-PE)

Periodic Processing PUBLIC 413
Activities

To access this report, on the SAP Easy Access screen, choose Payment Engine Periodic Processing
Correspondence Start Correspondence Printing (transaction /PE1/PRINT_CORR).

More Information

Correspondence (FS-PE-COR) [page 410]

Display Correspondence [page 414]

18.2.2 Display Correspondence

Use

You use this report to display correspondence that has been created in Payment Engine in a defined layout.

Prerequisites

You have defined the Customizing settings described in Start Correspondence Printing under Prerequisites. For
more information, see Start Correspondence Printing [page 411].

Features

The system displays a list of defined correspondence types, such as a non-execution confirmation or a
processing confirmation. You can select the correspondence data you want to display and define the list layout.

Selection

Correspondence data

• Clearing area
• Correspondence type
• Object date

Creation date

• Created by
• Date ID
• Identification

Payment Engine (FS-PE)

414 PUBLIC Periodic Processing
Output control

• Maximum number of hits

• Layout

Output

Depending on the layout settings you define, the following correspondence data can appear in the list:

• Correspondence type
• Issue date and issue time
Date and time when a correspondence request was created
• Print date
If applicable, date on which the correspondence was printed
• Sender
Business partner that sends the correspondence
• Original recipient
Business partner that receives the original correspondence
• Contract account
• Language in which you display and enter texts and print documents
• Transaction currency in which document is or was posted
• Amount of the payment transaction in the local currency
• Account managing area
• Correspondence recipient
Business partner to which correspondence is to be sent
• Internal contract ID
• Order party or recipient item reference number
• Data type for which the system creates correspondence, for example, purchase order

Activities

To access this report, on the SAP Easy Access screen, choose Payment Engine Periodic Processing
Correspondence Display Correspondence (transaction /PE1/ERROR_CORR).

More Information

Correspondence (FS-PE-COR) [page 410]

Start Correspondence Printing [page 411]

Payment Engine (FS-PE)

Periodic Processing PUBLIC 415
19 Logs

Use

You can display logs for monitoring business objects and processes in Payment Engine.

If you want to display a log entry that is related to a concrete object or an object-related event, for example,
the reconciliation date of a payment order has increased, you use the functional log. Otherwise, you use the
technical log.

Prerequisites

• You have defined the settings for functional logging in Customizing for Payment Engine under Tools
Logs Define Group Settings for Functional Log .
• You have defined the messages you want the functional log to record in Customizing for Payment Engine
under Tools Logs Define Message Settings for Functional Log .
• You have defined the process types you want the technical log to record based on the standard process
categories in Customizing for Payment Engine under Tools Logs Define Technical Log Settings .

Features

You can use the following functions for logging:

• Functional log
Records messages about business objects, such as payment orders, payment items, and collectors, and
events related to these objects in the business application log (BAL).
• Technical log
Records messages about technical processes, for example, accrual, collection of payment items, and
end-of-day processing, in the business application log (BAL).
• Message search for functional log and technical log
Searches for messages in the technical log and the functional log that the system records in the business
application log (BAL).
• Manage the log settings of the functional log and the technical log

 Note

This function is for expert users only.

Payment Engine (FS-PE)

416 PUBLIC Logs
Activities

• To display the technical log, on the SAP Easy Access screen, choose Payment Engine Logs Display
Technical Log (transaction /PE1/TECHLOG).
• To display the functional log, on the SAP Easy Access screen, choose Payment Engine Logs Display
Functional Log (transaction /PE1/SHOW_FUNC_LOG).
• To search for messages in the technical log and the functional log, on the SAP Easy Access screen, choose
Payment Engine Logs Search for Messages (transaction /PE1/LOG_SEARCH_MSG).
• To manage the settings of the technical log and the functional log, on the SAP Easy Access screen,
choose Payment Engine Logs Administration Settings Manage Log Settings (transaction /PE1/
LOG_SETTINGS).

19.1 Performance Analysis in the Performance Cockpit

Use

You use this function during runtime to display an overview of your mass processing, which enables you to
do an analysis. You can speed up processing by specifying that your mass processing report executes more
processes at one time. After processing has finished, you can display a log of the items processed.

Integration

You use this function in conjunction with other reports such as Asynchronous Poller for Processing Items
(/PE1/R_WRAP_COMM_POLLER) under Periodic Processing Communication with Account Management
System Asynchronous Poller for Processing Items in the SAP Easy Access menu for Payment Engine (FS-
PE).

Prerequisites

• To customize the maximum number of processes that can be specified in the Performance Cockpit,
execute the Customizing activity Configure Performance Cockpit (table /PE1/PC_CONFIG) in Customizing
for Payment Engine (FS-PE). Choose Tools Performance Configure Performance Cockpit or click
the Customizing button in the Performance Cockpit.

• To activate the logging function and ensure that the database is updated, you click the Activate PC
button in the application toolbar or select the FLG_ACTIVE checkbox in the above Customizing activity.
• To activate the Performance Cockpit for particular applications in the system, execute the Customizing
activity Activate Performance Cockpit for Applications in Customizing for Payment Engine (FS-PE). Choose
Tools Performance Activate Performance Cockpit for Applications .

Payment Engine (FS-PE)

Logs PUBLIC 417
Features

Comparison of Multiple Processes

You can compare multiple processes to analyze, for example, whether processing was slower on certain days
than others when other processes were running, or when the response times were slower from connected
systems such as the account managing system. Select the processes to be compared and choose
Compare. The results are displayed as a graph.

Display Options

You can display the analysis results as a graph or a list.

Process Data

This group box displays the key information about the processes, for example, the ID of the mass run, or
the number of processes with which the report was started (you can overwrite this value in the Customizing
activity mentioned above). You can also display a technical log for the mass run by choosing

Logging Data

The Performance Cockpit generates a log in the background about the number of items that were processed. If
you do not require a log, you can deactivate it by choosing Deactivate PC, which can speed up performance.

 Note

Once logged data is older than a certain number of days, you can delete this by executing the report Delete
Old Logging Data (see below).

Activities

• To call the Performance Cockpit from the SAP Easy Access menu, choose Payment Engine Logs
Performance Cockpit Start Performance Cockpit .
• To delete old logging data, choose Payment Engine Logs Performance Cockpit Delete Old Logging
Data .

Payment Engine (FS-PE)

418 PUBLIC Logs
20 Release Workflow

Use

You can use this function to trigger a release workflow whenever certain objects within Payment Engine are
changed. To avoid error situations caused by manual object changes, you can define a workflow that allows
dual, triple, or quadruple control over changed data. By cross-checking, you can authorize certain changes
before the objects are activated.

Features

You can set up a release workflow for the following objects.

Transaction Data

• Payment orders
For more information, see Release Object ORDER (Payment Order) [page 135].
• Payment items
For more information, see Release Object POITEM (Payment Item) [page 140].
• Recalls
For more information, see Release Object RECALL (Recall) [page 148].

Master Data

• Service level agreements

For more information, see Release Object SLA (Service Level Agreement) [page 261].
• Value date agreements and corresponding rules
For more information, see Release Object VA (Value Date Agreement) [page 253].
• Routes and corresponding rules
For more information, see Release Object ROUTE (Route) [page 214].
• Clearing agreements and corresponding rules
For more information, see Release Object CA (Clearing Agreement) [page 227].
• Customer agreements and corresponding rules
For more information, see Release Object CUSTAGR (Customer Agreement) [page 239].
• Exception control rules
For more information, see Release Object EH (Exception Control Rule Set) [page 280].

Payment Engine (FS-PE)

Release Workflow PUBLIC 419
21 Archiving (FS-PE-ARC)

Use

You use this component to remove data that is no longer required in Payment Engine (FS-PE) without
permanently deleting it. Archiving is used to move data that is no longer needed in daily business operations
from a given database to an archive, where it can be kept and accessed for as long as required by law. This also
improves system and database performance.

All data belonging to a business object, such as a payment order or a recall, is first copied to an archive file
and then deleted from the database. Business objects must fulfill certain technical and business criteria to be
considered archivable. One of the fundamental criteria is that they must have reached a specific age, called
residence time, before they can be archived.

The system moves deleted business objects from the operational databases, but you still have read access
to the archived data. You can display archived business objects in the same way as data still residing in the
database, but you cannot change them.

For more information about basic functions and procedures in data archiving, see SAP NetWeaver Platform
Function-Oriented View Solution Life Cycle Management Data Archiving Data Archiving in the ABAP
Application System Data Archiving with Archive Development Kit (ADK) .

Implementation Considerations

The archiving tools for Payment Engine (FS-PE) are preconfigured for archiving payment data. In Customizing
for Payment Engine (FS-PE), you can implement activities to adapt the archiving functions to your specific
needs.

Further Customizing options are available in the archiving tools themselves.

For more information, see Archiving Tools [page 422].

Integration

In archiving, business objects are represented as archiving objects. The Payment Engine (FS-PE) business
object payment order is represented by an archiving object that contains the data of the payment order itself,
its payment items, payment remittances, and all other referenced data.

Payment items referenced by more than one payment order, such as an incoming order or outgoing order, are
referenced as shared objects in each order. Shared objects can only be deleted when all referenced payment
orders have been deleted.

Payment Engine (FS-PE)

420 PUBLIC Archiving (FS-PE-ARC)
Features

The following archiving tasks are available for Payment Engine (FS-PE):

• Customizing archiving functions

You can make use of a number of functions to modify or to expand the archiving functions provided.
• Archiving and deleting payment data
You can archive payment orders, payment items, and recalls using the Archive Administration (transaction
SARA).
• Archiving other data
You can archive application logs, change data, and service level agreements (SLAs).
• Viewing archived data
You can view the archived data according to your selection criteria.

More Information

More information about the following subjects is available:

Subject See

Tools for archiving Archiving Tools [page 422]

Archiving, deleting, and displaying payment data Archiving Payment Data [page 424]

(including payment items and collectors)

Archiving logs and other data Archiving Logs and Documents [page 438]

Archiving with Archive Development Kit (ADK) SAP NetWeaver Platform Function-Oriented View

Solution Life Cycle Management Data Archiving Data

Archiving in the ABAP Application System Data Archiving

with Archive Development Kit (ADK)

21.1 Maintaining Customizing Settings in Archiving Tools

Use

You can maintain general Customizing using transaction SARA. When creating specific variants for an archiving
phase (preprocessing, write, deletion), you can select the maximum amount of objects per package. By
selecting Job Distr., you can distribute the created packages to multiple servers.

Payment Engine (FS-PE)

Archiving (FS-PE-ARC) PUBLIC 421
Procedure

For the residence time Customizing you have two options:

• If you have installed SAP Information Lifecycle Management (ILM), you can configure residence times for
all archiving objects. For all archiving objects there are corresponding ILM objects. Assign the ILM object to
audit area ARCHIVING using transaction ILMARA. Subsequently, start transaction IRMPOL. Create policies
for audit area Archiving in order to define residence times for the ILM object.
• In case you haven't installed ILM, you can as well define residence times using Customizing.

More Information

For more information about SAP Information Lifecycle Management, see the SAP ERP Library on SAP
Help Portal under http://help.sap.com/erp Cross-Application Functions Cross-Application Components
SAP Information Lifecycle Management.

21.2 Archiving Tools

Use

For archiving data in Payment Engine (FS-PE) and other functions, you use these tools:

• Archive Administration (transaction SARA).

The Archive Administration is the major tool for archiving tasks in Payment Engine (FS-PE). You use it to
archive payment orders, recalls, and request agents.
For more information, see Archive Administration (transaction SARA)
• Information Landscape Management
If you are using ILM the following features are available:
• Definition of residence times (Audit Area: ARCHIVING)
• Automatic deletion for archived files (Audit Area: GENERAL)
• Blocking of personal data (Audit Area: PE_DP)
• Archive Development Kit (ADK)
The Archive Development Kit (ADK) is a tool for developing archiving solutions. It also performs archiving
tasks in the background. You use it through the Archive Administration, for example, to archive logs and
change data.
For more information, see Archive Development Kit (ADK) [page 424].

More Information

Archiving Payment Data [page 424]

Payment Engine (FS-PE)

422 PUBLIC Archiving (FS-PE-ARC)
Archiving Logs and Documents [page 438]

21.2.1 ILM Integration

All archiving objects are assigned to corresponding ILM objects. Using transaction ILMARA, you can assign
ILM objects to audit areas. Subsequently, you can create rules using transaction IRMPOL for each audit area,
termed policies.

The following ILM objects are available:

• /PE1/ORD2 (Payment Orders)

• /PE1/COLL (Collector Categories)
• /PE1/RAG (Request Agents)
• /PE1/RCL (Recalls)
• /PE1/SLA (Sevice Level Agreements)
• /PE1/OL (Object Lists)

Integration of Account Management (FS-AM and IS-B-BCA)

In scenarios with SAP components FS-AM and IS-B-BCA an integrated Customizing is required. In detail, it is
required that payment items possess the same residence times with respect to blocking in both systems. This
can be achieved by reconciling the residence times and conditions fields in Payment Engine and the respective
account management system.

Residence Times for Archiving

You can define residence times for archiving using transaction IRMPOL for audit area ARCHIVING.

Blocking of Personal Data

You can automatically block personal data for archived payment the following way:

For archived payment data, a display from archive can be restricted after a certain time period. In order to
activate this feature, you need to define residence times for audit area PE_DP. After the defined residence
time within audit area PE_DP has expired, data from the archive will only be shown to users with specific
authorizations (authorization object S_IRM_DISP).

Automatic Deletion of Archive Files

You can automatically delete archived files the following way:

Assign ILM object (using transaction ILMARA) to an audit area of type Retention Period (RTP). For instance,
you can use audit area GENERAL for this purpose. Subsequently, create rules within this audit area using
transaction IRMPOL in order to define the expiration date.

Payment Engine (FS-PE)

Archiving (FS-PE-ARC) PUBLIC 423
21.2.2 Archive Development Kit (ADK)

Use

You use the Archive Development Kit (ADK) to develop archiving solutions. You can also use it to prepare the
runtime environment for archiving and to archive data other than payment orders and recalls in Payment
Engine.

The Archive Development Kit (ADK) is an intermediate layer between the application program and the archive
that provides all the functions required for archiving data. Its functions are needed for archiving and for
subsequent access to archived data. It often runs in the background during archiving processes.

For more information, see SAP NetWeaver Platform Function-Oriented View Solution Life Cycle
Management Data Archiving Data Archiving in the ABAP Application System Data Archiving with Archive
Development Kit (ADK) .

Activities

You can use the Archive Development Kit (ADK) to archive application logs, change documents, and service
level agreements (SLAs) through the Archive Administration using these transactions:

• /PE1/SBAL_AR_ARCH to archive application logs

• /PE1/CHDOC_AR_ARCH to archive change documents
• /PE1/SLA_AR_ARCH to archive other documents, such as service level agreements (SLAs)
• /PE1/RA_AR_ARCHIVING to archive request agents.

For more information, see Archiving Logs and Documents [page 438]

21.3 Archiving Payment Data

Use

You can use this process to archive, delete, and display payment orders and recalls in Payment Engine.

 Note

All order types, incoming orders, outgoing orders, and letters of advice (advice orders), use the same
archiving objects. There are no separate archiving objects for payment items and collectors. They are
archived as part of the referenced order.

Payment Engine (FS-PE)

424 PUBLIC Archiving (FS-PE-ARC)
Prerequisites

You have carried out Customizing activities to adapt the archiving processes for Payment Engine to your
requirements.

Process

Archiving Payment Orders

Payment Engine can process payment orders containing more than 1,000,000 payment items. Because of this
huge amount of data, one archiving object instance is not sufficient, as this would lead to runtime errors due to
memory overflow. Therefore, two archiving objects are used for payment orders:

• Order analysis (/PE1/ORD2)

This archiving object splits large payment orders into smaller technical order objects. For the residence
time determination you have the following options:
During the analysis, the residence time and business checks are also executed:
• Residence time check (ILM enabled)
You can specify residence rules for payment orders within audit area Archiving using transaction
IRMPOL.
• Residence time check (ILM disabled)
You can configure residence times using transaction AR_CUST
You can make more detailed settings on Clearing Area level using transaction AR_HDS. Since the
archiving object /PE1/ORD1, which performs residence time checks, is assigned to retention policy
procedure Hierarchical, the system internally evaluates all Customizing settings and checks whether
an order can be archived based on its residence time.

 Note

The residence time is calendar independent and can be maintained in days, weeks, months, or
years.

• Business check
The system only checks the payment order state and, thus, needs to read no other data. If the check
is positive, the system archives the object; if it is negative, it increases the resubmission date by the
period defined in the Archiving Engine Customizing.
Archiving is permitted, if one of the following states apply:
• Inbound processing finished
• Rejected
• Processed in Output Manager (OPM)
• Outbound processing finished
• Reversed
If a payment order can be archived, it is written as a single technical order object into table /PE1/
DB_ORDER_AR. A database buffer used as a header table for payment order and payment item archiving
(/PE1/ORD2).
If a payment order needs to be split, the system writes multiple technical order objects into table /PE1/
DB_ORDER_AR.

Payment Engine (FS-PE)

Archiving (FS-PE-ARC) PUBLIC 425
  Example

Using archiving object /PE1/ORD1, the system finds a payment order containing 1,000,000 payment
items. It splits this payment order into 100 packages of 10,000 items each and writes these packages
as technical order objects into table /PE1/DB_ORDER_AR.

For more information, see Archiving Payment Orders [page 427].

• Order archiving (/PE1/ORD2)
This archiving object archives the technical order objects.
Order archiving comprises writing and deleting phases:
• Write phase
All order entries in table /PE1/DB_ORDER_AR are written to archive files. No further checks are
necessary (neither residence time nor business checks)
• Delete phase
This phase is used to read the written archive files and delete the corresponding database table
entries.

 Note

The system does not delete payment items and payment-item dependent tables in this phase.

For more information, see Deleting Payment Items [page 436].

For more information, see Archiving Payment Orders [page 427] .

Archiving Recalls

The system uses only one archiving object for recalls, recall archiving (/PE1/RCL).

Recall archiving comprises these phases:

• Analysis phase
During the analysis, the system checks the residence time and performs the business checks.
• Write phase
All recall entries (in table /PE1/DB_RECALL) are written to archive files.
• Delete phase
The system reads the written archive file and deletes the corresponding database table entries.

 Note

The system does not delete payment items and payment-item dependent tables in this phase.

For more information, see Deleting Payment Items [page 436].

For more information, see Archiving Recalls [page 429].

Displaying Payment Orders and Archived Data

You can view payment orders in the archiving application.

For more information, see Displaying Payment Orders [page 437].

Payment Engine (FS-PE)

426 PUBLIC Archiving (FS-PE-ARC)
21.3.1 Archiving Payment Orders

Use

The system analyzes payment data in Payment Engine (FS-PE) using archiving object /PE1/ORD2. It analyzes:

• Incoming payment orders

• Outgoing payment orders
• Letters of advice (advice orders)

For more information, see Payment Processing (FS-PE-POP) [page 309].

 Note

The system handles payment items and collectors as part of the referenced payment order.

For more information, see Collector [page 346].

Using archiving object /PE1/ORD2 (Payment Engine: Order Analysis), the system can archive data listed
in table /PE1/DB_ORDER (Payment Orders in Payment Engine). You can add further tables to the standard
archiving functions by registering the corresponding read modules in the Archiving Engine tables. UI
integration for additional fields is supported generically. You must modify the UI as a customer development to
show additional tables and fields. Also, the data-retrieval function must be able to read the database as well as
archive files.

Before you can archive and delete payment data in Payment Engine (FS-PE), the system needs to perform:

• An analysis of the data

• A residence time check
• A business check

Payment orders are assigned to ILM object PE1_ORD2. The following condition fields are available:

• Clearing Area (Table field /PE1/DB_ORDER-CLEARING_AREA)

• Payment Order Type (Table field /PE1/DB_ORDER-PO_TYPE)

The following time references can be employed:

• Last change date (Table field /PE1/DB_ORDER- CHDAT)

Data Analysis

Because of the potentially large number of payment items in a given payment order, the system splits large
payment orders into smaller technical order objects. If a payment order can be archived, it is written into
table /PE1/DB_ORDER_AR. If an order needs to be split, the system writes multiple technical order objects into
table /PE1/DB_ORDER_AR. The system uses table /PE1/DB_ORDER_AR, a database buffer, as a header table
for payment data archiving (/PE1/ORD2).

 Note

The system archives payment data only if both of the following conditions are fulfilled:

• The residence time of the business objects has elapsed (residence time check).
• The processing state of the business objects is final (business check).

Payment Engine (FS-PE)

Archiving (FS-PE-ARC) PUBLIC 427
Residence Time Check

The system checks whether the residence time of the business object being analyzed has elapsed. The
residence time is the period of time between the last change date and the current date.

Business Check

Archiving is permitted, if one of the following states applies to the business object:

• Inbound processing finished

• Rejected
• Processed in OPM (Output Manager)
• Outbound processing finished
• Reversed

Writing Payment Data

Payment data, written in table /PE1/DB_ORDER_AR by archiving object /PE1/ORD2 in the analysis phase,
can be archived. The system uses this table as a header table for payment data archiving in the write phase.
Residence-time checks and business checks have already been carried out in the analysis phase.

You can use the Archive Administration (transaction DB15) to show tables of archiving objects and the objects
in the tables from which data is archived. You can also check the space statistics for any selected table.

Deleting Payment Data

Payment order data can be deleted after archiving, but the system retains shared objects in the database until
all referencing payment orders and recalls have been archived.

 Note

Payment items referenced by multiple payment orders cannot be deleted until all referencing payment
orders have been archived.

For more information, see Deleting Payment Items [page 436].

Procedure

Analysis Phase

On the Easy Access screen, choose Payment Engine (FS-PE) Archiving Archiving, Deleting, and
Displaying Payment Data Archiving Payment Orders (Archiving) (transaction /PE1/PO_AR_ARCHIVING).

You can now archive the payment orders that have been determined as archivable.

Write Phase

1. On the Easy Access screen, choose Payment Engine (FS-PE) Archiving Archiving,
Deleting, and Displaying Payment Data Archiving Payment Orders (Archiving) (transaction /PE1/
PO_AR_ARCHIVING).

 Note

To ensure that all available options appear, press Enter.

Payment Engine (FS-PE)

428 PUBLIC Archiving (FS-PE-ARC)
2. You can archive payment data from the following tables:

Table Content Available Activities

/PE1/DB_ORDER_AR Archiving payment orders (technical Archive and delete

orders including splits)

/PE1/DB_ORDER Payment orders in Payment Engine Archive and delete

(headers)

/PE1/DB_FH_ORDER File Handler payment order informa- Archive and delete

tion

/PE1/DB_FH_ORD_C Cluster table of File Handler payment Archive and delete

orders

/PE1/DB_COLLECT Table of collectors Archive and delete

/PE1/DB_EH_FCHCK Order-level checks including errors Archive and delete

/PE1/DB_ITEM Payment items in Payment Engine Archive only

(headers)

/PE1/DB_ACCR_DET Detail table of accruals Archive only

/PE1/DB_PAYM_REM Payment remittances in Payment Archive only

Engine (headers)

/PE1/DB_FH_ITEM File Handler payment-item informa- Archive only

tion

/PE1/DB_FH_ITM_C Cluster table of File Handler payment Archive only

items

/PE1/DB_EH_FCHCK Item-level checks including errors Archive only

3. Choose Execute.
The system confirms the successful execution of the selected task with a message.

21.3.2 Archiving Recalls

Use

The system analyzes and archives recalls in Payment Engine using archiving object /PE1/RCL. However, it only
archives recalls that are in one of these final states:

• Rejected
• Inactive
• Legally active

Payment Engine (FS-PE)

Archiving (FS-PE-ARC) PUBLIC 429
For more information, see Recall Processing [page 147].

Using archiving object /PE1/RCL (Payment Engine: Order Analysis), the system can archive data listed in
table /PE1/DB_RECALL.

 Note

The system archives payment data only if both of the following conditions are fulfilled:

• The residence-time of the business objects has elapsed (residence-time check).

• The processing state of the business objects is final (business check).

During the analysis, the system performs a residence-time check and a business check:

• Residence-Time Check
The system checks whether the residence time of the business object being analyzed has elapsed. The
residence time is the period of time between the last change date and the current date.
• Business Check
Archiving is permitted if one of the following states applies to the business object:
• Legally Active (350)
• Inactive (300)
Payment items that have been processed by the recall must also have a final state.

You can use Archive Administration (transaction DB15) to show tables of archiving objects and the objects in
the tables from which data is archived. You can also check the space statistics for any selected table.

Payment recalls are assigned to ILM object /PE1/RCL. The following condition fields are available:

• Clearing Area (/PE1/DB_RECALL-CLEARING_AREA)

• Recall Group (/PE1/DB_RECALL-RECALL_GROUP)
• Recall Type (/PE1/DB_RECALL-RECALL_TYPE)
• Recall Reason (/PE1/DB_RECALL-REASON)

The following time references can be employed:

• Valid-To Date (/PE1/DB_RECALL-VALID_TO)

• Last Change Date (/PE1/DB_RECALL-CHDAT)

Procedure

Starting Recall Analysis

1. On the SAP Easy Access screen, choose Payment Engine Archiving Archiving, Deleting, and
Displaying Payment Data Archiving Recalls (transaction /PE1/RC_AR_ARCHIVING).
2. In the SARA variant maintenance (optional):
• Select Job Distr. if you want the system to select all objects into smaller packages.
• Maintain the Package Size (the number of recalls per package).
3. Choose Preproc to start the analysis process.

Starting Recall Archiving

Payment Engine (FS-PE)

430 PUBLIC Archiving (FS-PE-ARC)
1. On the SAP Easy Access screen, choose Payment Engine Archiving Archiving, Deleting, and
Displaying Payment Data Archiving Recalls (transaction /PE1/RC_AR_ARCHIVING).
2. Choose Write to copy archivable objects to archive files.
You can archive payment data from the following tables:

Table Content Available Activities

/PE1/DB_RECALL Recall header Archive only

/PE1/DB_FH_REC_C File Handler recall information Archive only

/PE1/DB_RCL_MTCH Payment item match Archive only

In the SARA variant maintenance (optional):

1. Select Job Distr. if you want the system to all select objects into smaller packages.
2. Maintain the Package Size (the number of recalls per package).

3. Choose Delete to complete the archiving process by deleting objects from the corresponding database
tables.

21.3.3 Archiving Request Agents

Definition

This archiving object enables you to archive request agents from database table /PE1/DB_REQ_AGNT (for
recalls of SEPA credit transfers).

Request Agents are assigned to ILM object /PE1/RAG. The following condition fields are available:

• Clearing Area (/PE1/DB_REQ_AGNT-CLEARING_AREA)

• Request Agent Type (/PE1/DB_REQ_AGNT-AGENT_TYPE)
The following time references can be employed:
• Last Change Date (/PE1/DB_REQ_AGNT-CHDAT)
• Request Agent Expiry Date (/PE1/DB_REQ_AGNT-REQ_EXPIRY_DATE)

Structure

Analysis Phase

The system checks that the following applies before it archives request agents:

• The residence time specified has elapsed.

• The request agent status is either Completed (40) or Manually Closed (50).

If these checks fail, the system sets a resubmission date. Once this date has been reached, the system checks
again. If the checks are successful, the system archives the request agent during the next Write phase.

Payment Engine (FS-PE)

Archiving (FS-PE-ARC) PUBLIC 431
Integration

This archiving object is related to recalls of SEPA credit transfers (archived by archiving object /PE1/RCL). For
more information, see Archiving Recalls [page 429].

You can call the report that uses this archiving object from the SAP Easy Access screen by choosing Payment
Engine (FS-PE) Archiving Archiving, Deleting, and Displaying Payment Data Archiving Request Agents .

More Information

For more information about request agents, see Request Agent [page 150].

21.3.4 Archiving Collector Categories

Definition

When outgoing payment orders are archived, the corresponding collectors (where the sequential number is
not zero) are deleted. Collector categories whose sequential number is zero are not deleted. This archiving
object enables you to archive collector categories whose sequential number is zero from database table /PE1/
DB_COLLECT (for collectors).

This archiving object also enables you to archive queues. Unlike the collector categories, you also archive the
instances of the queue (payment items).

Collector categories are assigned to ILM object /PE1/COLL. The following condition fields are available:

• Clearing Area (/PE1/DTE_BPE_CLEARING_AREA)

• Clearing Agreement ID (/PE1/DTE_BPE_CLEARING_ID)
• Collection Type (/PE1/DTE_CP_COLLECT_KIND)
• Customer Agreement ID (/PE1/DTE_RP_CUSTAGR_ID)
• Transaction Debit/Credit (/PE1/DTE_BPE_DCFLG)
• Collector Direction (/PE1/DTE_CP_COLLECT_DIRECTION)
• Route ID (/PE1/DTE_BPE_ROUTE_ID)

The following time reference can be employed:

Time Stamp for Closing Time (/PE1/DTE_CP_CLOSE_TIMESTAMP)

Structure

Analysis Phase

Payment Engine (FS-PE)

432 PUBLIC Archiving (FS-PE-ARC)
The system checks that the following applies before it archives collector categories or queue categories:

• The residence time specified has elapsed.

 Note

You specify the residence time in the report Archiving Collector Categories and Queues by choosing the
configuration button from the application toolbar.

• The collector category status is 07 (Final Category) and there are no more collector instances.
• The queue category status is 07 (Final Category) and the status of its instances is 04 (Completed and
Posted).

If these checks fail, the system sets a resubmission date. Once this date has been reached, the system checks
again. If the checks are successful, the system archives the collector category during the next Write phase.

Write Phase

For more information, see Archive Administration (transaction SARA).

Delete Phase

For more information, see Archive Administration (transaction SARA).

Integration

This archiving object is related to payment orders (archived by archiving object /PE1/ORD2).

You can call the report that uses this archiving object from the SAP Easy Access screen by choosing
Payment Engine (FS-PE) Archiving Archiving, Deleting, and Displaying Payment Data Archiving
Collector Categories .

21.3.5 Archiving Service Level Agreements

Use

You archive service level agreements (SLAs) using the Archive Administration (SARA).

For more information, see Archive Development Kit (ADK) [page 424].

Procedure

1. On the Easy Access screen, choose Payment Engine Archiving Archiving Logs, Change Documents,
and SLAs Archiving Service Level Agreements (transaction /PE1/SLA_AR_ARCH).
2. Select the Actions to be performed.

Payment Engine (FS-PE)

Archiving (FS-PE-ARC) PUBLIC 433
3. Execute the selected action.

Alternatively, you can use transaction SARA to initiate archiving processes for any required archiving object.

Service level agreements are assigned to ILM object /PE1/SLA. The following condition fields are available:

• Clearing Area (/PE1/DTE_BPE_CLEARING_AREA)

• SLA Type (/PE1/DTE_BPE_SLA_TYPE)

The following time references can be employed:

• Last Date of SLA Validity (/PE1/DTE_PO_VALID_TO)

21.3.6 Archiving Object Lists

Use

You archive object lists using the Archive Administration (SARA).

For more information, see SAP NetWeaver Platform Function-Oriented View Solution Life Cycle
Management Data Archiving Data Archiving in the ABAP Application System Data Archiving with Archive
Development Kit (ADK)

Procedure

1. On the Easy Access screen, choose Payment Engine Archiving Archiving Logs, Change Documents,
and SLAs Archiving Service Level Agreements (transaction /PE1/OLIST_ARCHIVING).
2. Select the Actions to be performed.
3. Execute the selected action.

Alternatively, you can use transaction SARA to initiate archiving processes for any required archiving object.

Object lists are assigned to ILM object /PE1/OL. The following condition fields are available:

• Clearing Area (/PE1/DTE_BPE_CLEARING_AREA)

• Object List Type (/PE1/DTE_FH_OL_TYPE)

The following time references can be employed:

• Change Date (/PE1/DTE_BPE_CHDAT)

21.3.7 Archiving Bank File Clearing

You archive Bank File Clearing using the archiving object /PE1/BFC.

Transaction SARA (Archive Administration) is used to initiate archiving processes for any required archiving
object.

Payment Engine (FS-PE)

434 PUBLIC Archiving (FS-PE-ARC)
For more information, see Archive Development Kit (ADK) [page 424].

Bank File Clearing is assigned to ILM object PE1_BFC. The following condition field is available:

• Clearing Area (CLEARING_AREA Type /PE1/DTE_BPE_CLEARING_AREA)

The following time reference can be employed:

• LAST_CHANGE_DATE Type /PE1/DTE_BPE_CHDAT

Related Information

Bank File Clearing [page 202]

21.3.8 Archiving Value Date Data

You archive value dates and value date agreements using the archiving object /PE1/VA.

Transaction SARA (Archive Administration) is used to initiate archiving processes for any required archiving
object.

For more information, see Archive Development Kit (ADK) [page 424].

Value date data is assigned to ILM object PE1_VA. The following condition field is available:

• Clearing Area (CLEARING_AREA Type /PE1/DTE_BPE_CLEARING_AREA)

The following time reference can be employed:

• LAST_CHANGE_DATE Type /PE1/DTE_BPE_CHDAT

Related Information

Value Date Agreement [page 244]

21.3.9 Archiving Routes and Clearing Agreement Data

You archive routes and clearing agreement data using the archiving object /PE1/RN.

Transaction SARA (Archive Administration) is used to initiate archiving processes for any required archiving
object.

For more information, see Archive Development Kit (ADK) [page 424].

Value date data is assigned to ILM object PE1_RN. The following condition field is available:

• Clearing Area (CLEARING_AREA Type /PE1/DTE_BPE_CLEARING_AREA)

Payment Engine (FS-PE)

Archiving (FS-PE-ARC) PUBLIC 435
The following time reference can be employed:

• LAST_CHANGE_DATE Type /PE1/DTE_BPE_CHDAT

Related Information

Routing Control (FS-PE-RP) [page 205]

21.3.10 Deleting Payment Items

Context

You can delete payment items in the Payment Engine when all associated payment orders have been archived.

For more information, see Archiving Payment Orders [page 427].

Since payment items can be referenced by two or more payment orders, payment order archiving does not
trigger the deletion of payment items. Therefore, it is required to run an additional high performance report
(/PE1/PI_AR_DELETE) which facilitates the deletion of payment items.

For more information, see Archiving Payment Orders [page 427].

Procedure

1. On the SAP Easy Access screen, choose Payment Engine Archiving Archiving, Deleting, and
Displaying Payment Data Deleting Payment Items (/PE1/PI_AR_DELETE).
2. Choose the Clearing Area.
3. Select the Segmentation Key.
4. Select the Deletion Process.
5. Maintain the Technical Settings (optional).
6. Execute.

Payment Engine (FS-PE)

436 PUBLIC Archiving (FS-PE-ARC)
21.3.11 Displaying Payment Orders

Use

You can display payment orders in the archiving application and you can display archived data in Payment
Engine.

Procedure

Displaying Payment Orders and Collectors in the Archiving Application

1. On the SAP Easy Access screen, choose Payment Engine Archiving Archiving, Deleting, and
Displaying Payment Data Displaying Payment Orders (transaction /PE1/AR_ORD2_DISPLAY).
2. Choose a clearing area.
3. Choose Payment Order or Collector.
4. Define any additional parameters (optional).
You can filter the payment orders displayed by choosing the following criteria:
• Payment order date
• Payment order number
• Technical status
• Object list date
• Object list number
You can filter the collectors displayed by choosing the following criteria:
• Collector number
• Sequence number
• Collector date
• Collector status
• User who closed the collector
• Closing time
5. Define the maximum number of business objects you want to display.
6. Choose the data source Archive

 Note

You can also use this transaction to display payment orders and collector that are stored in the
Payment Engine database by choosing Database or Database and Archive.

Displaying Archived Data in Payment Engine

• To display archived payment orders, including incoming payment orders, outgoing payment orders, and
letters of advice:
1. On the SAP Easy Access screen, choose Payment Engine Payment Order Management Edit
Payment Orders (Expert) (transaction /PE1/PO_EXPERT).
2. Choose a clearing area.

Payment Engine (FS-PE)

Archiving (FS-PE-ARC) PUBLIC 437
 3. Choose Extras Change Data Source Archive .
For more information, see Edit Payment Orders (Expert) [page 373].
• To display archived payment collector data, including customer collectors, clearing collectors, and queues:
1. On the SAP Easy Access screen, choose Payment Engine Clearing Manage Collectors and
Queues (transaction /PE1/CP_COLL).
2. Choose a clearing area.
3. Choose Extras Change Data Source Archive .
• To display archived recall data, use the Business Application Programming Interface (BAPI) /PE1/
BAPI_RECALL_GETDETAIL. For information about how to manage recalls, see Recall Management [page
144].
• For information about how to display data that is archived in the File Handler Database, see Display File
Handler Database [page 298].

21.4 Archiving Logs and Documents

Use

You archive application logs, change documents, and service-level agreements (SLAs) in the Archive
Development Kit (ADK) [page 424] using archiving objects:

• BC_SBAL for application logs

• CHANGEDOC for change documents

Process

Using the Archiving Menu

You can use the Easy Access screen ( Payment Engine Archiving Archiving Logs, Change Documents, and
SLAs ) or specific transactions to:

• Archive application logs (transaction /PE1/SBAL_AR_ARCH)

For more information, see Archiving Application Logs [page 439].
• Archive change documents (transaction /PE1/CHDOC_AR_ARCH)
For more information, see Archiving Change Documents [page 439].

Using Transaction SARA

You can use transaction SARA to initiate archiving processes for any required archiving object:

1. On the Easy Access screen, enter transaction SARA.

The Archive Administration: Initial Screen appears.
2. Select the Archiving Object.
3. Select the Actions to be performed.

Payment Engine (FS-PE)

438 PUBLIC Archiving (FS-PE-ARC)
4. Execute the selected action.

21.4.1 Archiving Application Logs

Use

You archive application logs using the Archive Development Kit (ADK).

For more information, see Archive Development Kit (ADK) [page 424].

Procedure

1. On the Easy Access screen, choose Payment Engine Archiving Archiving Logs, Change Documents,
and SLAs Archiving Application Logs (transaction /PE1/CHDOC_AR_ARCH).
2. Select the Actions to be performed.
3. Execute the selected action.

Alternatively, you can use transaction SARA to initiate archiving processes for any required archiving object.

21.4.2 Archiving Change Documents

Use

You archive change documents using the Archive Development Kit (ADK).

For more information, see Archive Development Kit (ADK) [page 424].

Procedure

1. On the Easy Access screen, choose Payment Engine Archiving Archiving Logs, Change Documents,
and SLAs Archiving Change Documents (transaction /PE1/CHDOC_AR_ARCH).
2. Select the Actions to be performed.
3. Execute the selected action.

Alternatively, you can use transaction SARA to initiate archiving processes for any required archiving object.

Payment Engine (FS-PE)

Archiving (FS-PE-ARC) PUBLIC 439
22 Information System (FS-PE-IS)

Use

You use this component to evaluate the database online and to display the information in manageable units on
screen. You can create lists to enable the evaluation of the business data created in Payment Engine or to check
the results for the processing of the business objects. This supports repetitive standard evaluations and also
reports with a specific purpose.

The main data entities of the Information System comprise payment orders and payment items.

 Example

If you require an overview of the payment orders of a certain clearing area for your statistics or strategic
planning, you can use one of these reports.

You can analyze each area as required. You can schedule the generation in background jobs.

 Recommendation

We recommend that you generate the lists only in certain situations (for example, when end-of-day
processing is complete).

Features

You can run the following reports from the SAP Easy Access screen by choosing Information System:

• Overview: Functional Monitoring (transaction /PE1/FUNC_MON)

Displays functional monitoring data and gives you insights into the overall status of Payment Engine
by providing aggregated overviews of the following objects and their statuses: payment items, payment
orders, recalls, error IDs of payment items and payment orders, and collector data.
You can view detailed information about individual objects by using forward navigation to the respective
screens of the objects. In addition, connectivity of the Functional Monitoring screen to external systems
such as SAP Solution Manager is supported.
• Overview: Object Lists (transaction /PE1/FH_OLIST)
Lists the objects in files that are received or forwarded by File Handler.
• Overview: Payment Orders (transaction /PE1/PO_DISPLAY)
Displays information about payment orders submitted to or created in Payment Engine. For more
information, see Payment Order [page 133].
• Overview: Payment Items (transaction /PE1/PI_DISPLAY)
Displays information about payment items submitted to or created in Payment Engine including the
technical status of the payment items. For more information, see Payment Item [page 138].
• Overview: Additional Information (transaction /PE1/RM_DISPLAY)
Displays additional information about payment items, such as payment notes.

Payment Engine (FS-PE)

440 PUBLIC Information System (FS-PE-IS)
• Overview: Processes (transaction /PE1/RTI)
Displays all processes running in the system, enriched with additional information such as the number of
payment items that have been processed.

For more information, see the system documentation for the particular reports.

Constraints

This documentation does not apply to Information System for the general ledger transfer. In this case, the
selection criteria and evaluation options are different due to technical differences in the format.

Payment Engine (FS-PE)

Information System (FS-PE-IS) PUBLIC 441
23 DataSources in SAP Payment Engine

You can use the DataSources in Payment Engine (FS-PE) to transfer data to SAP NetWeaver Business
Warehouse. You can find more information about the BI Content provided in SAP NetWeaver Business
Warehouse for this component at http://help.sap.com/paymentengine under Integration & Analytics
Information.

23.1 Master Data

23.1.1 Payment Order Types

0PE_PAYMENT_ORDER_TYPE_ATTR

Use

Using this DataSource you can load payment order types into the BI system. This is a generic view extraction of
the values.

This DataSource is needed to enhance the uploaded transactional data for orders by the payment order
category. The /PE1/DB_ORDER only contains the order type, whereas the requested selection in order queries
is order category. By replication of this information to the BI system, the missing data can be added during the
BI data transformation process.

Technical Data

Application Component Payment Engine (FS-PE)

Exchange Available as of Release Payment Engine 3.00, SP02

Shipment BI Content 705 (SAP NetWeaver 7.0, BI Content Add-On 5)

Content Versions PAY300

RemoteCube-Capable No

Delta-Capable No

Payment Engine (FS-PE)

442 PUBLIC DataSources in SAP Payment Engine
Extraction from Archives No

Verifiable No

Data Modeling

Fields of Origin for the Extraction Structure

Fields in the Extraction Description of the Field in

Structure the Extraction Structure Table of Origin Field in the Table of Origin

CLEARING_AREA Clearing area /PE1/T_POTYPE CLEARING_AREA

PO_TYPE PO type /PE1/T_POTYPE PO_TYPE

PO_KIND PO category /PE1/T_POTYPE PO_KIND

23.1.2 Service Level Agreement Attributes

0PE_SLA_ATTR

Use

Using this DataSource you can load service level agreements (SLAs) into the BI system. This is a generic view
extraction of the values.

This DataSource replicates only those entries in table /PE1/DB_SLA that have release status 03 (released).

The following attributes are needed to build queries:

• Clearing Area SLA

• Segment SLA
• Customer SLA

Technical Data

Application Component Payment Engine (FS-PE)

Exchange Available as of Release Payment Engine 3.00, SP02

Shipment BI Content 705 (SAP NetWeaver 7.0, BI Content Add-On 5)

Content Versions PAY300

Payment Engine (FS-PE)

DataSources in SAP Payment Engine PUBLIC 443
RemoteCube-Capable No

Delta-Capable No

Extraction from Archives No

Verifiable No

Data Modeling

Fields of Origin for the Extraction Structure

Fields in the Extraction Description of the Field in

Structure the Extraction Structure Table of Origin Field in the Table of Origin

CLEARING_AREA Clearing area /PE1/DB_SLA CLEARING_AREA

SLA_ID Service Level Agreement /PE1/DB_SLA SLA_ID

SLA_DATE SLA date /PE1/DB_SLA SLA_DATE

SLA_TYPE SLA type /PE1/DB_SLA SLA_TYPE

SEGMENT_ID Segment /PE1/DB_SLA SEGMENT_ID

CUSTOMER_ID Customer /PE1/DB_SLA CUSTOMER_ID

23.2 Flow Data

23.2.1 Object List Data

0PE_OBJECT_LIST_TRAN

Use

Using this DataSource you can load object list data into the BI system. This is a generic view extraction
of the values. This is a function module extraction of the values. The extract structure includes table /PE1/
DB_OLIST.

The following fields are visible by default:

• OL_DATE
• OL_NO

Payment Engine (FS-PE)

444 PUBLIC DataSources in SAP Payment Engine
• OL_TYPE
• IN_OUT_FORMAT
• CHANNEL
• TECH_STAT
• CLEARING_AREA
• FH_START_DATE
• CRDAT
• CHDAT
• RECORDMODE

Technical Data

Application Component Payment Engine (FS-PE)

Exchange Available as of Release Payment Engine 3.00, SP02

Shipment BI Content 705 (SAP NetWeaver 7.0, BI Content Add-On 5)

Content Versions PAY300

RemoteCube-Capable No

Delta-Capable Delta via snapshot on CHDAT

Extraction from Archives No

Verifiable No

Data Modeling

Delta Update
The CHDAT field is used for delta detection.

 Recommendation

We recommend that you schedule the BI replication after the payment order processing (late evening or
during the night), and that you use today's date if this is before midnight, and yesterday's date if this is after
midnight.

Therefore, it is not possible to replicate the data during the day. This is because it is only possible to
differentiate by date, and data could be replicated multiple times, thus overloading the system.

Fields of Origin for the Extraction Structure

Fields in the Extraction Description of the Field in

Structure the Extraction Structure Table of Origin Field in the Table of Origin

OL_DATE OL Date /PE1/DB_OLIST OL_DATE

Payment Engine (FS-PE)

DataSources in SAP Payment Engine PUBLIC 445
Fields in the Extraction Description of the Field in
Structure the Extraction Structure Table of Origin Field in the Table of Origin

OL_NO OL Number /PE1/DB_OLIST OL_NO

OL_TYPE OL Type /PE1/DB_OLIST OL_TYPE

IN_OUT_FORMAT Obj. List Format /PE1/DB_OLIST IN_OUT_FORMAT

CHANNEL Channel /PE1/DB_OLIST CHANNEL

TECH_STAT Techn. Status /PE1/DB_OLIST TECH_STAT

CLEARING_AREA Clearing Area /PE1/DB_OLIST CLEARING_AREA

FH_START_DATE FH Start Date /PE1/DB_OLIST FH_START_DATE

CRDAT Created on /PE1/DB_OLIST CRDAT

CHDAT Changed on /PE1/DB_OLIST CHDAT

RECORD_MODE Record Mode /PE1/DB_OLIST RECORD_MODE

Extractor Logic

 Note

The CLEARING_AREA field is no key field for object lists.

23.2.2 Payment Item Data

0PE_PAYMENT_ITEM_TRAN

Use

Using this DataSource you can load payment item data into the BI system. The extraction is executed by a
function module. The extract structure includes table /PE1/DB_ITEM. The selection by a segmentation key
allows parallelization of the data replication process.

Field ONE_UPLOAD is calculated as follows:

• TRUE, if CHDAT = CRDAT and TECH_STAT is final. Since the item cannot be changed anymore it will only be
uploaded once.
• FALSE in all other cases.

Using this logic, the BI can send the uploaded data to different DataStore objects, write enabled (for
ONE_UPLOAD = TRUE) and delta enabled (for ONE_UPLOAD = FALSE), to avoid multiple values for one object.

The following fields are visible by default:

• CLEARING_AREA
• PI_DATE

Payment Engine (FS-PE)

446 PUBLIC DataSources in SAP Payment Engine
• PI_NO
• RECORDMODE
• SEGMENTATION_KEY
• TECH_STAT
• PI_KIND
• REF_ROUTE
• ONE_UPLOAD
• REF_CLEARING
• REF_CUSTAGR
• TR_CURR
• TR_AMOUNT
• TRANS_TYPE
• CRDAT
• CHDAT

Technical Data

Application Component Payment Engine (FS-PE)

Exchange Available as of Release Payment Engine 3.00, SP02

Shipment BI Content 705 (SAP NetWeaver 7.0, BI Content Add-On 5)

Content Versions PAY300

RemoteCube-Capable No

Delta-Capable No

Extraction from Archives No

Verifiable No

Data Modeling

Delta Update
The CHDAT field is used for delta detection.

 Recommendation

We recommend that you schedule the BI replication after the payment order processing (late evening or
during the night), and that you use today's date if this is before midnight, and yesterday's date if this is after
midnight.

Therefore, it is not possible to replicate the data during the day. This is because it is only possible to
differentiate by date, and data could be replicated multiple times, thus overloading the system.

Payment Engine (FS-PE)

DataSources in SAP Payment Engine PUBLIC 447
Fields of Origin for the Extraction Structure

Fields in the Extraction Description of the Field in

Structure the Extraction Structure Table of Origin Field in the Table of Origin

CLIENT Client /PE1/DB/ITEM CLIENT

CLEARING_AREA Clearing Area /PE1/DB/ITEM CLEARING_AREA

PI_DATE Payment Item Date /PE1/DB/ITEM PI_DATE

PI_NO Payment Item Number from /PE1/DB/ITEM PI_NO

Number Range

SEGMENTATION_KEY Segmentation Criteria for DB /PE1/DB/ITEM SEGMENTATION_KEY

Tables

TECH_STAT Technical Status of Payment /PE1/DB/ITEM TECH_STAT

Item

PI_KIND Payt Item Cat. /PE1/DB/ITEM PI_KIND

REF_ROUTE Route /PE1/DB/ITEM REF_ROUTE

REF_CLEARING Clearing Agree. /PE1/DB/ITEM REF_CLEARING

REF_CUSTAGR Customer Agree. /PE1/DB/ITEM REF_CUSTAGR

TR_CURR Trans. Currency /PE1/DB/ITEM TR_CURR

TR_AMOUNT Amount /PE1/DB/ITEM TR_AMOUNT

TRANS_TYPE PE Trans. Type /PE1/DB/ITEM TRANS_TYPE

CR_DAT Created On /PE1/DB/ITEM CR_DAT

CHDAT Change Date /PE1/DB/ITEM CHDAT

ONE_UPLOAD One Upload /PE1/DB/ITEM ONE_UPLOAD

RECORD_MODE Record Mode /PE1/DB/ITEM RECORD_MODE

23.2.3 Payment Order Data

0PE_PAYMENT_ORDER_TRAN

Use

Using this DataSource you can load payment order data into the BI system. The extraction is executed by a
function module. The extract structure includes table /PE1/DB_ORDER. The selection by a segmentation key
allows parallelization of the data replication process.

Field ONE_UPLOAD is calculated as follows:

• TRUE, if CHDAT = CRDAT and TECH_STAT is final. Since the item cannot be changed anymore it will only be
uploaded once.
• FALSE in all other cases.

Payment Engine (FS-PE)

448 PUBLIC DataSources in SAP Payment Engine
Using this logic, the BI can send the uploaded data to different DataStore objects, write enabled (for
ONE_UPLOAD = TRUE) and delta enabled (for ONE_UPLOAD = FALSE), to avoid multiple values for one object.

The following fields are visible by default:

• SEGMENTATION_KEY
• CLEARING_AREA
• PO_DATE
• PO_NO
• TECH_STAT
• PO_TYPE
• IN_OUT_FORMAT
• CHANNEL
• REF_CUST_SGM
• CNT_ORP_ITEMS
• CNT_RCP_ITEMS
• CNT_CLR_ITEMS
• CNT_TOV_ITEMS
• CNT_ERR_RCP_I
• SUM_ITEMS
• SUM_CURR
• CUST_SLA_ID
• CUST_SLA_DATE
• SEG_SLA_ID
• SEG_SLA_DATE
• CA_SLA_ID
• CA_SLA_DATE
• CRDAT
• CHDAT
• ONE_UPLOAD
• RECORDMODE

Technical Data

Application Component Payment Engine (FS-PE)

Exchange Available as of Release Payment Engine 3.00, SP02

Shipment BI Content 705 (SAP NetWeaver 7.0, BI Content Add-On 5)

Content Versions PAY300

RemoteCube-Capable No

Delta-Capable No

Payment Engine (FS-PE)

DataSources in SAP Payment Engine PUBLIC 449
Extraction from Archives No

Verifiable No

Data Modeling

Delta Update
The CHDAT field is used for delta detection.

 Recommendation

We recommend that you schedule the BI replication after the payment order processing (late evening or
during the night), and that you use today’s date if this is before midnight, and yesterday’s date if this is after
midnight.

Therefore, it is not possible to replicate the data during the day. This is because it is only possible to
differentiate by date, and data could be replicated multiple times, thus overloading the system.

Fields of Origin for the Extraction Structure

Fields in the Extraction Description of the Field in

Structure the Extraction Structure Table of Origin Field in the Table of Origin

CLIENT Client /PE1/DB_ORDER CLIENT

SEGMENTATION_KEY Segment. Key /PE1/DB_ORDER SEGMENTATION_KEY

CLEARING_AREA Clearing Area /PE1/DB_ORDER

PO_DATE PO Date /PE1/DB_ORDER PO_DATE

PO_NO Order No. /PE1/DB_ORDER PO_NO

TECH_STAT PO Tech. Status /PE1/DB_ORDER TECH_STAT

PO_TYPE Order Type /PE1/DB_ORDER PO_TYPE

IN_OUT_FORMAT Format /PE1/DB_ORDER IN_OUT_FORMAT

CHANNEL Channel /PE1/DB_ORDER CHANNEL

REF_CUST_SGM Cust. Seg. REF_CUST_SGM

CNT_ORP_ITEMS Number ORP /PE1/DB_ORDER CNT_ORP_ITEMS

CNT_RCP_ITEMS Number RCP Item /PE1/DB_ORDER CNT_RCP_ITEMS

CNT_CLR_ITEMS No. Clr. Items /PE1/DB_ORDER CNT_CLR_ITEMS

CNT_TOV_ITEMS No.TurnoverItms /PE1/DB_ORDER CNT_TOV_ITEMS

CNT_ERR_RCP_I No.Incorr.RCPItem /PE1/DB_ORDER CNT_ERR_RCP_I

SUM_ITEMS Sum Amounts /PE1/DB_ORDER SUM_ITEMS

SUM_CURR Curr Amount Total /PE1/DB_ORDER SUM_CURR

CUST_SLA_ID Customer SLA ID /PE1/DB_ORDER CUST_SLA_ID

Payment Engine (FS-PE)

450 PUBLIC DataSources in SAP Payment Engine
Fields in the Extraction Description of the Field in
Structure the Extraction Structure Table of Origin Field in the Table of Origin

CUST_SLA_DATE Customer SLA Date /PE1/DB_ORDER CUST_SLA_DATE

SEG_SLA_ID Segment SLA ID /PE1/DB_ORDER SEG_SLA_ID

SEG_SLA_DATE Segment SLA Date /PE1/DB_ORDER SEG_SLA_DATE

CA_SLA_ID Clearing Area SLA ID /PE1/DB_ORDER CA_SLA_ID

CA_SLA_DATE CA SLA Date /PE1/DB_ORDER CA_SLA_DATE

CRDAT Created On /PE1/DB_ORDER CRDAT

CHDAT Changed on /PE1/DB_ORDER CHDAT

ONE_UPLOAD One Upload / /

RECORDMODE Record Mode / /

23.2.4 Payment Item Aggregated Data Extractor

0PE_PAYMITEM_RECONC_AGGR_TRAN

Use

This DataSource enables reconciliation between the account managment system and Payment Engine (FS-PE)
through BW.

Using this DataSource, you can load aggregated reconciliation data for payment items into the BI system.

Technical Data

Application Component Payment Engine (FS-PE)

Exchange Available as of Release Payment Engine 3.00, SP04

Shipment BI Content 705 (SAP NetWeaver 7.0, BI Content Add-On 5)

Content Versions PAY300

RemoteCube-Capable No

Delta-Capable Yes

Extraction from Archives No

Verifiable No

Payment Engine (FS-PE)

DataSources in SAP Payment Engine PUBLIC 451
Data Modeling

Fields of Origin for the Extraction Structure

Fields in the Extraction Description of the Field in

Structure the Extraction Structure Table of Origin Field in the Table of Origin

AMOUNT_SUM Amount of Reconciliation Ob- /PE1/DB_RECONC AMOUNT_SUM

jects

AM_AREA Account Managing Area /PE1/DB_RECONC AM_AREA

BS_KEY_NAME Key Name of Business Sys- Filled automatically Filled automatically

tem by a function module by a function module

CURRENCY Transaction Currency /PE1/DB_RECONC TR_CURR

DEBCREDIND Debit or Credit /PE1/DB_RECONC TR_DEBCREDIND

LAST_CHANGED Number of Reconciliation /PE1/DB_RECONC LAST_CHANGED

Objects

OBJECT_COUNT UTC Time Stamp in Short /PE1/DB_RECONC OBJECT_COUNT

Form (YYYYMMDDhhmmss)

PI_KIND Payment Item Category /PE1/DB_RECONC PI_KIND

PI_POST_DATE Payment Item Category /PE1/DB_RECONC PI_POST_DATE

RECONC_CLUSTER Reconciliation Cluster in View /PE1/DB_RECONC RECONC_CLUSTER

of Various Areas, such as In-
ternal Items

RECONC_DATE Reconciliation Date /PE1/DB_RECONC RECONC_DATE

RECONC_KEY_ID Reconciliation Key /PE1/DB_RECONC RECONC_KEY_ID

STATE Technical Status in DB /PE1/DB_RECONC STATE

UPDMODE BW Delta Process: Record Filled automatically Filled automatically

Mode by a function module by a function module

23.2.5 Payment Item Detailed Data Extractor

0PE_PAYMITEM_RECONC_DETL_TRAN

Use

This DataSource enables reconciliation between the account management system and Payment Engine (FS-
PE) through BW.

Using this DataSource, you can load detailed reconciliation data for payment items into the BI system. This is a
generic extraction of the fixed values.

Payment Engine (FS-PE)

452 PUBLIC DataSources in SAP Payment Engine
Technical Data

Application Component Payment Engine (FS-PE)

Exchange Available as of Release Payment Engine 3.00, SP04

Shipment BI Content 705 (SAP NetWeaver 7.0, BI Content Add-On 5)

Content Versions PAY300

RemoteCube-Capable Yes

Delta-Capable No

Extraction from Archives No

Verifiable No

Data Modeling

Fields of Origin for the Extraction Structure

Fields in the Extraction Description of the Field in

Structure the Extraction Structure Table of Origin Field in the Table of Origin

AMOUNT Amount in Transaction Cur- /PE1/DB_RECONC-AMOUNT AMOUNT_SUM

rency

AM_AREA Account Managing Area /PE1/DB_RECONC AM_AREA

BS_KEY_NAME Key Name of Business Sys- Filled automatically Filled automatically

tem by a function module by a function module

CURRENCY Transaction Currency /PE1/DB_RECONC TR_CURR

DEBCREDIND Debit or Credit /PE1/DB_RECONC TR_DEBCREDIND

RECONC_DATE Reconciliation Date /PE1/DB_RECONC RECONC_DATE

RECONC_KEY_ID Reconciliation Key /PE1/DB_RECONC RECONC_KEY_ID

RECONC_OBJ_ID Reconciliation Key /PE1/DB_RECONC RECONC_OBJECT

SYS_SPEC_OBJ_ID System-Specific Object ID /PE1/DB_ITEM CLEARING_AREA,

for Reconciliation PI_DATE, PI_NO

UPDMODE BW Delta Process: Record Filled automatically Filled automatically

Mode by a function module by a function module

23.2.6 Payment Order Aggregated Data Extractor

0PE_PO_RECONC_AGGR_TRAN

Payment Engine (FS-PE)

DataSources in SAP Payment Engine PUBLIC 453
Use

This DataSource enables reconciliation between the account managment system and Payment Engine (FS-PE)
through BW.

Using this DataSource, you can load aggregated reconciliation data for payment orders into the BI system.

Technical Data

Application Component Payment Engine (FS-PE)

Exchange Available as of Release Payment Engine 3.00, SP04

Shipment BI Content 705 (SAP NetWeaver 7.0, BI Content Add-On 5)

Content Versions PAY300

RemoteCube-Capable No

Delta-Capable Yes

Extraction from Archives No

Verifiable No

Data Modeling

Fields of Origin for the Extraction Structure

Fields in the Extraction Description of the Field in

Structure the Extraction Structure Table of Origin Field in the Table of Origin

AMOUNT_SUM Amount of Reconciliation Ob- /PE1/DB_RECONC AMOUNT_SUM

jects

BS_KEY_NAME Key Name of Business Sys- Filled automatically Filled automatically

tem by a function module by a function module

CURRENCY Transaction Currency /PE1/DB_RECONC TR_CURR

LAST_CHANGED Number of Reconciliation /PE1/DB_RECONC LAST_CHANGED

Objects

OBJECT_COUNT UTC Time Stamp in Short /PE1/DB_RECONC OBJECT_COUNT

Form (YYYYMMDDhhmmss)

RECONC_DATE Reconciliation Date /PE1/DB_RECONC RECONC_DATE

RECONC_KEY_ID Reconciliation Key /PE1/DB_RECONC RECONC_KEY_ID

UPDMODE BW Delta Process: Record Filled automatically Filled automatically

Mode by a function module by a function module

Payment Engine (FS-PE)

454 PUBLIC DataSources in SAP Payment Engine
23.2.7 Payment Order Detailed Data Extractor

0PE_PO_RECONC_DETAIL_TRAN

Use

This DataSource enables reconciliation between the account managment system and Payment Engine (FS-PE)
through BW.

Using this DataSource, you can load detailed reconciliation data for payment orders into the BI system. This is
a generic extraction of the fixed values.

Technical Data

Application Component Payment Engine (FS-PE)

Exchange Available as of Release Payment Engine 3.00, SP04

Shipment BI Content 705 (SAP NetWeaver 7.0, BI Content Add-On 5)

Content Versions PAY300

RemoteCube-Capable Yess

Delta-Capable No

Extraction from Archives No

Verifiable No

Data Modeling

Fields of Origin for the Extraction Structure

Fields in the Extraction Description of the Field in

Structure the Extraction Structure Table of Origin Field in the Table of Origin

AMOUNT_SUM Amount of Reconciliation Ob- /PE1/DB_RECONC_AMOUNT AMOUNT_SUM

jects

BS_KEY_NAME Key Name of Business Sys- Filled automatically Filled automatically

tem by a function module by a function module

CURRENCY Transaction Currency /PE1/DB_RECONC TR_CURR

RECONC_DATE Reconciliation Date /PE1/DB_RECONC RECONC_DATE

RECONC_KEY_ID Reconciliation Key /PE1/DB_RECONC RECONC_KEY_ID

RECONC_OBJ_ID Reconciliation Key /PE1/DB_RECONC RECONC_OBJECT

Payment Engine (FS-PE)

DataSources in SAP Payment Engine PUBLIC 455
Fields in the Extraction Description of the Field in
Structure the Extraction Structure Table of Origin Field in the Table of Origin

SYS_SPEC_OBJ_ID System-Specific Object ID /PE1/DB_RECONC, /PE1/ CLEARING_AREA,

for Reconciliation DB_ORDER PI_DATE, PI_NO

UPDMODE BW Delta Process: Record Filled automatically Filled automatically

Mode by a function module by a function module

23.2.8 Reconciliation Hub: Payment Item Aggregated Data

Extractor

0PE_RH_PAYMITEM_AGGR_TRAN

Use

This DataSource enables reconciliation between an account management system and Payment Engine (FS-PE)
through SAP NetWeaver Business Warehouse. Using this DataSource, you can load aggregated reconciliation
data for payment items into the BI system.

Technical Data

Application Component Payment Engine (FS-PE)

Exchange Available as of Release SAP Payment Engine 8.0

Shipment BI Content 705 (SAP NetWeaver 7.0, BI Content Add-On 5)

Content Versions PAY400

RemoteCube-Capable No

Delta-Capable Yes

Extraction from Archives No

Verifiable No

Prerequisites

The system only extracts payment items that have status A (aggregated) (see table /PE1/DB_RECONC,
field STATE). Therefore, before data extraction, you must compress the data (transaction /PE1/
COMP_RECON_DATA).

Payment Engine (FS-PE)

456 PUBLIC DataSources in SAP Payment Engine
Data Modeling

Delta Update
A delta update is supported: AIE After-Images Via Extractor

Fields of Origin for the Extraction Structure

Fields in the Extraction Description of the Field in

Structure the Extraction Structure Table of Origin Field in the Table of Origin

UPDMODE BW Delta Process: Record Filled automatically Fixed value = space

Mode in extractor (After-Image

BS_KEY_NAME Key Name of Business Sys- Filled automatically Filled automatically

tem by a function module by a function module

RECONC_DATE Reconciliation Date /PE1/DB_RECONC RECONC_DATE

RECONC_ID Reconciliation Key /PE1/DB_RECONC Concatenation of

RECONC_SYSTEM,
RECONC_APPL, RECONC_ID

BUSINESS_AREA Business Area for Reconcilia- /PE1/DB_RECONC CLEARING_AREA

tion

FLAG_CREDIT Credit flag /PE1/DB_RECONC TR_DEBCREDIND

(TR_DEBCREDIND = D ->
FLAG_CREDIT = <blank>,
TR_DEBCREDIND = C ->
FLAG_CREDIT = X

CURRENCY Transaction Currency /PE1/DB_RECONC TR_CURR

LAST_CHANGED Timestamp /PE1/DB_RECONC LAST_CHANGED

ITEM_SUM Amount of Reconciliation Ob- /PE1/DB_RECONC AMOUNT_SUM

jects

ITEM_CNT Number of Reconciliation /PE1/DB_RECONC OBJECT_COUNT

Items

PI_POST_DATE Payment Item Posting Date /PE1/DB_RECONC PI_POST_DATE

RECONC_CLUSTER Reconciliation cluster /PE1/DB_RECONC RECONC_CLUSTER

PI_KIND Payment Item Type (01=Or- /PE1/DB_RECONC PI_KIND

dering Party, 02=Recipient,
03=Clearing, 04=Turnover)

OBJECT_CATG Reconciliation Object Type Filled automatically Fixed value = 02

(Item/Order) in extractor (payment item)

Extractor Logic
The extractor contains the mandatory selection parameter BUSINESS_AREA (selection option EQ) and the
extraction method is using function module /PE1/PEBW_RH_PAYMITEM_AGGR. You can specify multiple
selection parameters.

The business area has to be provided as a concatenation of clearing area and AM area separated by a space.

The system selects the data from table /PE1/DB_RECONC, the entries are compressed, and the number of
items belonging to this collection and the sum are saved in the ITEM_CNT and ITEM_SUM fields.

Payment Engine (FS-PE)

DataSources in SAP Payment Engine PUBLIC 457
23.2.9 Reconciliation Hub: Payment Item Detailed Data
Extractor

0PE_RH_PAYMITEM_DETL_TRAN

Use

This DataSource enables reconciliation between an account management system and Payment Engine (FS-
PE) through through SAP NetWeaver Business Warehouse. Using this DataSource, you can load detailed
reconciliation data for payment items into the BI system.

Technical Data

Application Component Payment Engine (FS-PE)

Exchange Available as of Release SAP Payment Engine 8.0

Shipment BI Content 705 (SAP NetWeaver 7.0, BI Content Add-On 5)

Content Versions PAY400

RemoteCube-Capable Yes

Delta-Capable Yes

Extraction from Archives No

Verifiable No

Data Modeling

Delta Update
A delta update is supported: AIE After-Images Via Extractor

Fields of Origin for the Extraction Structure

Fields in the Extraction Description of the Field in

Structure the Extraction Structure Table of Origin Field in the Table of Origin

UPDMODE BW Delta Process: Record Filled automatically Fixed value = space

Mode in extractor (After-Image)

BS_KEY_NAME Key Name of Business Sys- Filled automatically Filled automatically

tem by a function module by a function module

RECONC_DATE Reconciliation Date /PE1/DB_RECONC RECONC_DATE

Payment Engine (FS-PE)

458 PUBLIC DataSources in SAP Payment Engine
Fields in the Extraction Description of the Field in
Structure the Extraction Structure Table of Origin Field in the Table of Origin

RECONC_ID Reconciliation Key /PE1/DB_RECONC Concatenation of

RECONC_SYSTEM,
RECONC_APPL, RECONC_ID

BUSINESS_AREA Business Area for Reconcilia- /PE1/DB_RECONC Concatenation of

tion CLEARING_AREA and
AM_AREA

FLAG_CREDIT Credit flag /PE1/DB_RECONC_D TR_DEBCREDIND

(TR_DEBCREDIND = D ->
FLAG_CREDIT = <blank>,
TR_DEBCREDIND = C ->
FLAG_CREDIT = X)

OBJECT_CATG Reconciliation Object Type Filled automatically Fixed value = 02

(Item/Order) in extractor (payment item)

RECONC_OBJ_ID Reconciliation Object ID /PE1/DB_ITEM REF_ITEM_EXT

RECON_SYS_OBJ_ID System-Specific Object ID /PE1/DB_RECONC_D Concatenation of

for Reconciliation CLEARING_AREA,
NUMBER_ID, OBJECT_DATE

CURRENCY Transaction Currency /PE1/DB_ITEM TR_CURR

AMOUNT Amount of Reconciliation Ob- /PE1/DB_ITEM TR_AMOUNT

jects

Extractor Logic
The extractor contains the mandatory selection parameters RECONC_DATE, RECONC_ID, and BUSINESS_AREA
and the extraction method is performed using function module /PE1/PEBW_RH_PAYMORDER_DETL. You can
specify multiple occurrences of RECONC_DATE and RECONC_ID.

You can only specify the business area once. The business area has to be provided as a concatenation of the
clearing area and the AM area separated by space.

First the system selects the reconciliation details from table /PE1/DB_RECONC_D to retrieve the payment item
numbers and dates. Based on this information, from table /PE1/DB_ITEM, the systems selects the amount,
currency, credit indicator, and reconciliation object ID (which is mapped from the external payment item
reference (REF_ITEM_EXT)). The extractor also returns the system-specific object ID, which is a concatenation
of clearing area, payment item date, and payment item ID.

23.2.10 Reconciliation Hub: Payment Order Aggregated Data

Extractor

0PE_RH_PAYMORDER_AGGR_TRAN

Payment Engine (FS-PE)

DataSources in SAP Payment Engine PUBLIC 459
Use

This DataSource enables reconciliation between an account management system and Payment Engine (FS-PE)
through SAP NetWeaver Business Warehouse.

Using this DataSource, you can load aggregated reconciliation data for payment orders into the BI system.

Technical Data

Application Component Payment Engine (FS-PE)

Exchange Available as of Release SAP Payment Engine 8.0

Shipment BI Content 705 (SAP NetWeaver 7.0, BI Content Add-On 5)

Content Versions PAY400

RemoteCube-Capable No

Delta-Capable Yes

Extraction from Archives No

Verifiable No

Prerequisites

The system only extracts payment orders that have status A (aggregated) (see table /PE1/DB_RECONC,
field STATE). Therefore, before data extraction, you must compress the data (transaction /PE1/
COMP_RECON_DATA).

Data Modeling

Delta Update
A delta update is supported: AIE After-Images Via Extractor

Fields of Origin for the Extraction Structure

Fields in the Extraction Description of the Field in

Structure the Extraction Structure Table of Origin Field in the Table of Origin

UPDMODE BW Delta Process: Record Filled automatically Fixed value = space

Mode in extractor (After-Image

BS_KEY_NAME Key Name of Business Sys- Filled automatically Filled automatically

tem by a function module by a function module

Payment Engine (FS-PE)

460 PUBLIC DataSources in SAP Payment Engine
Fields in the Extraction Description of the Field in
Structure the Extraction Structure Table of Origin Field in the Table of Origin

RECONC_DATE Reconciliation Date /PE1/DB_RECONC RECONC_DATE

RECONC_ID Reconciliation Key /PE1/DB_RECONC Concatenation of

RECONC_SYSTEM,
RECONC_APPL, RECONC_ID

BUSINESS_AREA Business Area for Reconcilia- /PE1/DB_RECONC CLEARING_AREA

tion

LAST_CHANGED Timestamp /PE1/DB_RECONC LAST_CHANGED

CURRENCY Transaction Currency /PE1/DB_RECONC TR_CURR

AMOUNT Amount of Reconciliation Ob- /PE1/DB_RECONC AMOUNT_SUM

jects

OBJECT_CNT Number of Reconciliation /PE1/DB_RECONC OBJECT_COUNT

Items

OBJECT_CATG Reconciliation Object Type Filled automatically Fixed value = 01

(Item/Order) in extractor (payment order)

RECONC_CLUSTER Reconciliation cluster /PE1/DB_RECONC RECONC_CLUSTER

Extractor Logic

The extractor contains the mandatory selection parameter BUSINESS_AREA (selection option EQ) and the
extraction method is performed using function module /PE1/PEBW_RH_PAYMORDER_AGGR. You can specify
multiple selection parameters.

Payment orders are selected only by the clearing area; therefore, the value defined for the business area
corresponds to the clearing area.

The system selects the data from table /PE1/DB_RECONC, the entries are compressed and the number of
items belonging to this collection and the sum are saved in the AMOUNT and OBJECT_CNT fields.

The system only selects payment orders with RECONC_CLUSTER: ORDER_INCOMING or ORDER_OUTGOING.

23.2.11 Reconciliation Hub: Payment Order Detailed Data

Extractor

0PE_RH_PAYMORDER_DETL_TRAN

Use

This DataSource enables reconciliation between an account management system and Payment Engine (FS-PE)
through SAP NetWeaver Business Warehouse. Using this DataSource, you can load detailed reconciliation data
for payment orders into the BI system.

Payment Engine (FS-PE)

DataSources in SAP Payment Engine PUBLIC 461
Technical Data

Application Component Payment Engine (FS-PE)

Exchange Available as of Release SAP Payment Engine 8.0

Shipment BI Content 705 (SAP NetWeaver 7.0, BI Content Add-On 5)

Content Versions PAY400

RemoteCube-Capable Yes

Delta-Capable Yes

Extraction from Archives No

Verifiable No

Data Modeling

Delta Update

A delta update is only possible when you upload all data.

Fields of Origin for the Extraction Structure

Fields in the Extraction Description of the Field in

Structure the Extraction Structure Table of Origin Field in the Table of Origin

UPDMODE BW Delta Process: Record Filled automatically Fixed value = space

Mode in extractor (After-Image)

BS_KEY_NAME Key Name of Business Sys- Filled automatically Filled automatically

tem by a function module by a function module

RECONC_DATE Reconciliation Date /PE1/DB_RECONC RECONC_DATE

RECONC_ID Reconciliation Key /PE1/DB_RECONC Concatenation of

RECONC_SYSTEM,
RECONC_APPL, RECONC_ID

BUSINESS_AREA Business Area for Reconcilia- /PE1/DB_RECONC CLEARING_AREA

tion

OBJECT_CATG Reconciliation Object Type Filled automatically Fixed value = 01

(Item/Order) in extractor (payment order)

RECONC_OBJ_ID Reconciliation Object ID /PE1/DB_ORDER REF_EXT_PO

RECON_SYS_OBJ_ID System-Specific Object ID /PE1/DB_RECONC_D Concatenation of

for Reconciliation CLEARING_AREA,
NUMBER_ID, OBJECT_DATE

CURRENCY Transaction Currency /PE1/DB_RECONC TR_CURR

AMOUNT Amount of Reconciliation Ob- /PE1/DB_RECONC AMOUNT_SUM

jects

Payment Engine (FS-PE)

462 PUBLIC DataSources in SAP Payment Engine
Extractor Logic
The extractor contains the mandatory selection parameters RECONC_DATE, RECONC_ID, and BUSINESS_AREA,
and the extraction method is performed using function module /PE1/PEBW_RH_PAYMORDER_DETL. You can
specify multiple occurrences of RECONC_DATE and RECONC_ID. You can only specify the business area once.

Payment orders are selected only by the clearing area; therefore, the value defined in business area
corresponds to the clearing area.

First the system selects the reconciliation details from table /PE1/DB_RECONC_D to retrieve the payment
order numbers and dates. Based on this information, from the /PE1/DB_ORDER table, the system retrieves the
amount, currency, and reconciliation object ID (which is mapped from the external payment order reference
(REF_EXT_PO)). The extractor also returns the system specific object ID, which is a concatenation of clearing
area, payment order date, and payment order ID.

The system only selects payment orders with RECONC_CLUSTER: ORDER_INCOMING or ORDER_OUTGOING.

23.3 Texts

23.3.1 Format Texts

0PE_0PE_FORMAT_TEXT

Use

Using this DataSource you can load format texts into the BI system. This is a generic extraction of the values.

Technical Data

Application Component Payment Engine (FS-PE)

Exchange Available as of Release Payment Engine 3.00, SP02

Shipment BI Content 705 (SAP NetWeaver 7.0, BI Content Add-On 5)

Content Versions PAY300

RemoteCube-Capable No

Delta-Capable No

Extraction from Archives No

Payment Engine (FS-PE)

DataSources in SAP Payment Engine PUBLIC 463
Verifiable No

Data Modeling

Fields of Origin for the Extraction Structure

Fields in the Extraction Description of the Field in

Structure the Extraction Structure Table of Origin Field in the Table of Origin

SPRAS Language key /PE1/T_FORMATT SPRAS

FORMAT_IN_OUT Format /PE1/T_FORMATT FORMAT_IN_OUT

FORMATT_S Short text (length 15) /PE1/T_FORMATT FORMATT_S

FORMATT_L Long text (length 40) /PE1/T_FORMATT FORMATT_L

23.3.2 PE Channel Texts

0PE_CHANNEL_TEXT

Use

Using this DataSource, you can load channel texts into the BI system. This is a generic view extraction.

Technical Data

Application Component Payment Engine (FS-PE)

Exchange Available as of Release Payment Engine 3.00, SP02

Shipment BI Content 705 (SAP NetWeaver 7.0, BI Content Add-On 5)

Content Versions PAY300

RemoteCube-Capable No

Delta-Capable No

Extraction from Archives No

Verifiable No

Payment Engine (FS-PE)

464 PUBLIC DataSources in SAP Payment Engine
Data Modeling

Fields of Origin for the Extraction Structure

Fields in the Extraction Description of the Field in

Structure the Extraction Structure Table of Origin Field in the Table of Origin

SPRAS Language key /PE1/T_CHANNELT SPRAS

CLEARING_AREA Clearing Area /PE1/T_CHANNELT CLEARING_AREA

CHANNEL Channel /PE1/T_CHANNELT CHANNEL

CHANNEL_S Short text (length 15) /PE1/T_CHANNELT CHANNEL_S

CHANNEL_L Short text (length 40) /PE1/T_CHANNELT CHANNEL_L

23.3.3 Clearing Agreement Texts

0PE_CLEARING_AGREEMENT_TEXT

Use

Using this DataSource, you can load clearing agreement texts into the BI system. This is a generic extraction of
the fixed values. It only replicates entries in table /PE1/DB_CAT that have release status 03 (released).

Technical Data

Application Component Payment Engine (FS-PE)

Exchange Available as of Release Payment Engine 3.00, SP02

Shipment BI Content 705 (SAP NetWeaver 7.0, BI Content Add-On 5)

Content Versions PAY300

RemoteCube-Capable No

Delta-Capable No

Extraction from Archives No

Verifiable No

Payment Engine (FS-PE)

DataSources in SAP Payment Engine PUBLIC 465
Data Modeling

Fields of Origin for the Extraction Structure

Fields in the Extraction Description of the Field in

Structure the Extraction Structure Table of Origin Field in the Table of Origin

CLEARING_AREA Clearing area /PE1/DB_CAT CLEARING_AREA

ROUTE_ID Route /PE1/DB_CAT ROUTE_ID

CLEARING_ID Clearing agreement /PE1/DB_CAT CLEARING_ID

SSPRAS Language key /PE1/DB_CAT SSPRAS

CLEARING_NAME Text (length 30) /PE1/DB_CAT CLEARING_NAME

23.3.4 Clearing Area Texts

0PE_CLEARING_AREA_TEXT

Use

Using this DataSource you can load clearing area texts into the BI system. This is a generic extraction of the
fixed values.

Technical Data

Application Component Payment Engine (FS-PE)

Exchange Available as of Release Payment Engine 3.00, SP02

Shipment BI Content 705 (SAP NetWeaver 7.0, BI Content Add-On 5)

Content Versions PAY300

RemoteCube-Capable No

Delta-Capable No

Extraction from Archives No

Verifiable No

Payment Engine (FS-PE)

466 PUBLIC DataSources in SAP Payment Engine
Data Modeling

Fields of Origin for the Extraction Structure

Fields in the Extraction Description of the Field in

Structure the Extraction Structure Table of Origin Field in the Table of Origin

SPRAS Language key /PE1/T_CLAREAT SPRAS

SPRAS Language key /PE1/T_CLAREAT SPRAS

CLEARING_AREA_S Short text (length 15) /PE1/T_CLAREAT CLEARING_AREA_S

CLEARING_AREA_L Long text (length 40) /PE1/T_CLAREAT CLEARING_AREA_L

23.3.5 Customer Agreement Texts

0PE_CUSTOMER_AGREEMENT_TEXT

Use

Using this DataSource you can load customer agreement texts into the BI system. This is a generic view
extraction of the values. It only replicates entries in table /PE1/DB_CAT that have release status 03 (released).

Technical Data

Application Component Payment Engine (FS-PE)

Exchange Available as of Release Payment Engine 3.00, SP02

Shipment BI Content 705 (SAP NetWeaver 7.0, BI Content Add-On 5)

Content Versions PAY300

RemoteCube-Capable No

Delta-Capable No

Extraction from Archives No

Verifiable No

Payment Engine (FS-PE)

DataSources in SAP Payment Engine PUBLIC 467
Data Modeling

Fields of Origin for the Extraction Structure

Fields in the Extraction Description of the Field in

Structure the Extraction Structure Table of Origin Field in the Table of Origin

CLEARING_AREA Clearing area /PE1/V_CU_AGR_BI CLEARING_AREA

ROUTE_ID Route /PE1/V_CU_AGR_BI ROUTE_ID

CUSTAGR_ID Customer agreement /PE1/V_CU_AGR_BI CUSTAGR_ID

LANGUAGE Language key /PE1/V_CU_AGR_BI LANGUAGE

CUSTAGR_NAME Text (length 30) /PE1/V_CU_AGR_BI CUSTAGR_NAME

23.3.6 Object List Type Texts

0PE_OBJECT_LIST_TYPE_TEXT

Use

Using this DataSource you can load object list type texts into the BI system. This is a generic view extraction of
the values.

Technical Data

Application Component Payment Engine (FS-PE)

Exchange Available as of Release Payment Engine 3.00, SP02

Shipment BI Content 705 (SAP NetWeaver 7.0, BI Content Add-On 5)

Content Versions PAY300

RemoteCube-Capable No

Delta-Capable No

Extraction from Archives No

Verifiable No

Payment Engine (FS-PE)

468 PUBLIC DataSources in SAP Payment Engine
Data Modeling

Fields of Origin for the Extraction Structure

Fields in the Extraction Description of the Field in

Structure the Extraction Structure Table of Origin Field in the Table of Origin

SPRAS Language key /PE1/T_OLTYPET SPRAS

OL_TYPE Object list type /PE1/T_OLTYPET OL_TYPE

OL_TYPET_S Short text (length 15) /PE1/T_OLTYPET OL_TYPET_S

OL_TYPET_L Long text (length 40) /PE1/T_OLTYPET OL_TYPET_L

23.3.7 Payment Item Category Texts

0PE_PAYMENT_ITEM_CATEG_TEXT

Use

Using this DataSource you can load payment item category texts into the BI system. This is a generic
extraction of the fixed domain value.

Technical Data

Application Component Payment Engine (FS-PE)

Exchange Available as of Release Payment Engine 3.00, SP02

Shipment BI Content 705 (SAP NetWeaver 7.0, BI Content Add-On 5)

Content Versions PAY300

RemoteCube-Capable No

Delta-Capable No

Extraction from Archives No

Verifiable No

Payment Engine (FS-PE)

DataSources in SAP Payment Engine PUBLIC 469
Data Modeling

Fields of Origin for the Extraction Structure

Fields in the Extraction Description of the Field in

Structure the Extraction Structure Table of Origin Field in the Table of Origin

LANGU Language key DD07T DDLANGUAGE

KEY1 Key field DD07T VALPOS

TXTLG Long text (length 60) DD07T DDTEXT

23.3.8 Payment Order Category Texts

0PE_PAYMENT_ORDER_CATEG_TEXT

Use

Using this DataSource you can load payment order category texts into the BI system. This is a generic view
extraction of the values.

Technical Data

Application Component Payment Engine (FS-PE)

Exchange Available as of Release Payment Engine 3.00, SP02

Shipment BI Content 705 (SAP NetWeaver 7.0, BI Content Add-On 5)

Content Versions PAY300

RemoteCube-Capable No

Delta-Capable No

Extraction from Archives No

Verifiable No

Payment Engine (FS-PE)

470 PUBLIC DataSources in SAP Payment Engine
Data Modeling

Fields of Origin for the Extraction Structure

Fields in the Extraction Description of the Field in

Structure the Extraction Structure Table of Origin Field in the Table of Origin

SPRAS Language key /PE1/T_PO_KINDT SPRAS

PO_KIND PO category /PE1/T_PO_KINDT PO_KIND

PO_KINDT_S Short text (length 15) /PE1/T_PO_KINDT PO_KINDT_S

PO_KINDT_L Long text (length 40) /PE1/T_PO_KINDT PO_KINDT_L

23.3.9 Payment Order Type Texts

0PE_PAYMENT_ORDER_TYPE_TEXT

Use

Using this DataSource you can load payment order type texts into the BI system. This is a generic view
extraction of the values.

Technical Data

Application Component Payment Engine (FS-PE)

Exchange Available as of Release Payment Engine 3.00, SP02

Shipment BI Content 705 (SAP NetWeaver 7.0, BI Content Add-On 5)

Content Versions PAY300

RemoteCube-Capable No

Delta-Capable No

Extraction from Archives No

Verifiable No

Payment Engine (FS-PE)

DataSources in SAP Payment Engine PUBLIC 471
Data Modeling

Fields of Origin for the Extraction Structure

Fields in the Extraction Description of the Field in

Structure the Extraction Structure Table of Origin Field in the Table of Origin

CLEARING_AREA Clearing area /PE1/T_POTYPET CLEARING_AREA

SPRAS Language key /PE1/T_POTYPET SPRAS

PO_TYPE PO type /PE1/T_POTYPET PO_TYPE

PO_TYPET_S Short text (length 15) /PE1/T_POTYPET PO_TYPET_S

PO_TYPET_L Long text (length 40) /PE1/T_POTYPET PO_TYPET_L

23.3.10 SLA Type Texts

0PE_SLA_TYPE_TEXT

Use

Using this DataSource you can load service level agreement (SLA) type texts into the BI system.

Technical Data

Application Component Payment Engine (FS-PE)

Exchange Available as of Release Payment Engine 3.00, SP02

Shipment BI Content 705 (SAP NetWeaver 7.0, BI Content Add-On 5)

Content Versions PAY300

RemoteCube-Capable No

Delta-Capable No

Extraction from Archives No

Verifiable No

Payment Engine (FS-PE)

472 PUBLIC DataSources in SAP Payment Engine
Data Modeling

Fields of Origin for the Extraction Structure

Fields in the Extraction Description of the Field in

Structure the Extraction Structure Table of Origin Field in the Table of Origin

LANGUAGE Language key /PE1/T_SLA_TYPET LANGUAGE

SLA_TYPE SLA type /PE1/T_SLA_TYPET SLA_TYPE

DESCR_S Short text (length 15) /PE1/T_SLA_TYPET DESCR_S

DESCR_L Long text (length 40) /PE1/T_SLA_TYPET DESCR_L

23.3.11 Service Level Agreement Texts

0PE_SLA_TEXT

Use

Using this DataSource you can load service level agreement (SLA) texts into the BI system. This is a generic
view extraction of the values. This DataSource replicates only those entries in table /PE1/DB_SLA that have
release status 03 (released).

Technical Data

Application Component Payment Engine (FS-PE)

Exchange Available as of Release Payment Engine 3.00, SP02

Shipment BI Content 705 (SAP NetWeaver 7.0, BI Content Add-On 5)

Content Versions PAY300

RemoteCube-Capable No

Delta-Capable No

Extraction from Archives No

Verifiable No

Payment Engine (FS-PE)

DataSources in SAP Payment Engine PUBLIC 473
Data Modeling

Fields of Origin for the Extraction Structure

Fields in the Extraction Description of the Field in

Structure the Extraction Structure Table of Origin Field in the Table of Origin

CLEARING_AREA Clearing area /PE1/DB_SLA CLEARING_AREA

SLA_ID Service Level Agreement /PE1/DB_SLA SLA_ID

SLA_DATE SLA date /PE1/DB_SLA SLA_DATE

SLA_DESCR Medium text (length 25) /PE1/DB_SLA SLA_DESCR

23.3.12 Route Texts

0PE_ROUTE_TEXT

Use

Using this DataSource you can load route texts into the BI system. This is a generic view extraction of the
values.

This DataSource replicates only those entries in table /PE1/DB_ROUTET that have release status 03 (released).

Technical Data

Application Component Payment Engine (FS-PE)

Exchange Available as of Release Payment Engine 3.00, SP02

Shipment BI Content 705 (SAP NetWeaver 7.0, BI Content Add-On 5)

Content Versions PAY300

RemoteCube-Capable No

Delta-Capable No

Extraction from Archives No

Verifiable No

Payment Engine (FS-PE)

474 PUBLIC DataSources in SAP Payment Engine
Data Modeling

Fields of Origin for the Extraction Structure

Fields in the Extraction Description of the Field in

Structure the Extraction Structure Table of Origin Field in the Table of Origin

CLEARING_AREA Clearing area /PE1/DB_ROUTET CLEARING_AREA

ROUTE_ID Route /PE1/DB_ROUTET ROUTE_ID

SSPRAS Language key /PE1/DB_ROUTET SSPRAS

ROUTE_NAME Medium text (length 30) /PE1/DB_ROUTET ROUTE_NAME

23.3.13 Segment Texts

0PE_SEGMENT_TEXT

Use

Using this DataSource you can load segment texts into the BI system. This is a generic view extraction of the
values.

Technical Data

Application Component Payment Engine (FS-PE)

Exchange Available as of Release Payment Engine 3.00, SP02

Shipment BI Content 705 (SAP NetWeaver 7.0, BI Content Add-On 5)

Content Versions PAY300

RemoteCube-Capable No

Delta-Capable No

Extraction from Archives No

Verifiable No

Payment Engine (FS-PE)

DataSources in SAP Payment Engine PUBLIC 475
Data Modeling

Fields of Origin for the Extraction Structure

Fields in the Extraction Description of the Field in

Structure the Extraction Structure Table of Origin Field in the Table of Origin

CLEARING_AREA Clearing area /PE1/T_SEGMENTT CLEARING_AREA

LANGUAGE Language key /PE1/T_SEGMENTT LANGUAGE

SEGMENT Segment /PE1/T_SEGMENTT SEGMENT

SEGMENT_S Short text (length 15) /PE1/T_SEGMENTT SEGMENT_S

SEGMENT_L Long text (length 40) /PE1/T_SEGMENTT SEGMENT_L

23.3.14 Transaction Type Texts

0PE_TRANSACTION_TYPE_TEXT

Use

Using this DataSource you can load transaction type texts into the BI system. This is a generic view extraction
of the values.

Technical Data

Application Component Payment Engine (FS-PE)

Exchange Available as of Release Payment Engine 3.00, SP02

Shipment BI Content 705 (SAP NetWeaver 7.0, BI Content Add-On 5)

Content Versions PAY300

RemoteCube-Capable No

Delta-Capable No

Extraction from Archives No

Verifiable No

Payment Engine (FS-PE)

476 PUBLIC DataSources in SAP Payment Engine
Data Modeling

Fields of Origin for the Extraction Structure

Fields in the Extraction Description of the Field in

Structure the Extraction Structure Table of Origin Field in the Table of Origin

CLEARING_AREA Clearing area /PE1/T_TRNSTYPET CLEARING_AREA

SPRAS Language key /PE1/T_TRNSTYPET SPRAS

TRANS_TYPE Transaction Type /PE1/T_TRNSTYPET TRANS_TYPE

TRANS_TYPET_S Short text (length 15) /PE1/T_TRNSTYPET TRANS_TYPET_S

TRANS_TYPET_L Long text (length 40) /PE1/T_TRNSTYPET TRANS_TYPET_L

Payment Engine (FS-PE)

DataSources in SAP Payment Engine PUBLIC 477
Important Disclaimers and Legal Information

Hyperlinks
Some links are classified by an icon and/or a mouseover text. These links provide additional information.
About the icons:

• Links with the icon : You are entering a Web site that is not hosted by SAP. By using such links, you agree (unless expressly stated otherwise in your
agreements with SAP) to this:

• The content of the linked-to site is not SAP documentation. You may not infer any product claims against SAP based on this information.

• SAP does not agree or disagree with the content on the linked-to site, nor does SAP warrant the availability and correctness. SAP shall not be liable for any
damages caused by the use of such content unless damages have been caused by SAP's gross negligence or willful misconduct.

• Links with the icon : You are leaving the documentation for that particular SAP product or service and are entering an SAP-hosted Web site. By using
such links, you agree that (unless expressly stated otherwise in your agreements with SAP) you may not infer any product claims against SAP based on this
information.

Videos Hosted on External Platforms

Some videos may point to third-party video hosting platforms. SAP cannot guarantee the future availability of videos stored on these platforms. Furthermore, any
advertisements or other content hosted on these platforms (for example, suggested videos or by navigating to other videos hosted on the same site), are not within
the control or responsibility of SAP.

Beta and Other Experimental Features

Experimental features are not part of the officially delivered scope that SAP guarantees for future releases. This means that experimental features may be changed by
SAP at any time for any reason without notice. Experimental features are not for productive use. You may not demonstrate, test, examine, evaluate or otherwise use
the experimental features in a live operating environment or with data that has not been sufficiently backed up.
The purpose of experimental features is to get feedback early on, allowing customers and partners to influence the future product accordingly. By providing your
feedback (e.g. in the SAP Community), you accept that intellectual property rights of the contributions or derivative works shall remain the exclusive property of SAP.

Example Code
Any software coding and/or code snippets are examples. They are not for productive use. The example code is only intended to better explain and visualize the syntax
and phrasing rules. SAP does not warrant the correctness and completeness of the example code. SAP shall not be liable for errors or damages caused by the use of
example code unless damages have been caused by SAP's gross negligence or willful misconduct.

Bias-Free Language
SAP supports a culture of diversity and inclusion. Whenever possible, we use unbiased language in our documentation to refer to people of all cultures, ethnicities,
genders, and abilities.

Payment Engine (FS-PE)

478 PUBLIC Important Disclaimers and Legal Information
Payment Engine (FS-PE)
Important Disclaimers and Legal Information PUBLIC 479
www.sap.com/contactsap

© 2023 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. The information contained herein may be changed
without prior notice.

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 or its affiliated companies shall not be liable for errors or
omissions with respect to the materials. The only warranties for SAP 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.

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. All
other product and service names mentioned are the trademarks of their
respective companies.

Please see https://www.sap.com/about/legal/trademark.html for

additional trademark information and notices.

THE BEST RUN