payment engine (fs-pe)

Application Help | PUBLICSAP Payment EngineDocument Version: 1.5 – 2020-06-26

Payment Engine (FS-PE)

© 2

020

SAP

SE o

r an

SAP affi

liate

com

pany

. All r

ight

s re

serv

ed.

THE BEST RUN

Content

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

2 Changes and New Features in SAP Payment Engine 9.0 SP01. . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 Changes and New Features in SAP Payment Engine 9.0 SP02. . . . . . . . . . . . . . . . . . . . . . . . . 24


5 Changes and New Features in SAP Payment Engine 9.0 SP04. . . . . . . . . . . . . . . . . . . . . . . . . .31





10 End-to-End Payment Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66

11 Basic Cross-Border STP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6911.1 Cross-Border Payment Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

12 Payment Processes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7412.1 Request for Cancellation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Active Request for Cancellation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Passive Request for Cancellation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

12.2 Recall of SEPA Credit Transfers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81Active Recall of SEPA Credit Transfers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Passive Recall of SEPA Credit Transfers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

12.3 Cash Pooling with Request for Transfer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8912.4 Foreign Exchange (Overview). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90

Foreign Exchange Rates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9012.5 Batch Booking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9212.6 Card Transaction Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Authorization Request Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94Financial Request Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Authorization Reversal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

13 Clearing Area. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

14 Payment Order. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

2 PUBLICPayment Engine (FS-PE)

Content

14.1 Release Object ORDER (Payment Order). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

15 Payment Item. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10615.1 Release Object POITEM (Payment Item). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

16 Recall. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11016.1 Recall Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11216.2 Recall Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11516.3 Release Object RECALL (Recall). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

17 Request Agent. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118

18 Connection of Internal and External Systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12118.1 Enterprise Services for Payment Engine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Application Management Framework. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124Payment Transaction Order In/Event Out. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125Payment Engine Connector. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

18.2 Connection to an Account Management System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13418.3 FI Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13618.4 CML Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13718.5 Connection to an Embargo System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13818.6 Connection to a Liquidity Management System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

19 Referential Data Interface (FS-PE-RDI). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14019.1 Routing Directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141

Upload of Referential Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14219.2 Standard Settlement Instructions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

Upload of Referential Data (Standard Settlement Instructions). . . . . . . . . . . . . . . . . . . . . . . . . 14619.3 Bank Master Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

Upload of Referential Data (Bank Master Data). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149Business Partner Generation (Offline). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

19.4 Account Substitution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

20 Master Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15520.1 Rule Set. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

Determining Business Objects with Rule Sets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15720.2 Charges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

Editing Charge Conditions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .166Differentiation Categories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

20.3 Bank File Clearing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169Manage Bank File Clearing Accounts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

20.4 Routing Control (FS-PE-RP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172Route. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174Clearing Agreement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

Payment Engine (FS-PE)Content PUBLIC 3

Customer Agreement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198Value Date Agreement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .211

20.5 Service Level Agreement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223Managing Service Level Agreements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226Release Object SLA (Service Level Agreement). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .228Status and Release Status of Master Data Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230

20.6 Exception Control (FS-PE-EH). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231Response Category. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233Response Type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235Correction Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236Exception Control Rule Set. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238Foreign Exchange (FX). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250Processing of Active Returns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251Full Rejection of Payment Orders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253Partial Rejection of Payment Orders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .254

21 File Handler (FS-PE-FH). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25521.1 Input Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

Import File (Expert). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25921.2 Output Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26121.3 File Handler Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

Display File Handler Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26421.4 XML Converter Framework. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265

ISO 20022 Converter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267ISO 8583 Converter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268SWIFT Converter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

21.5 Financial Services Network Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27021.6 Eurogiro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27121.7 Notification of Payment Order Processing Status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

22 Payment Processing (FS-PE-POP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27422.1 Enrichment and Validation (FS-PE-EV). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276

Check Processing Date. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277Enrichment and Validation Check. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278Enrichment and Validation Check Set. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295Embargo Check. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298Enrichment and Validation for Outgoing Payment Orders. . . . . . . . . . . . . . . . . . . . . . . . . . . . .299

22.2 Routing Control Overview (FS-PE-RP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301

23 Clearing Processing (FS-PE-CP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30223.1 Queue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304

Setting Up Queues and Collectors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307


Content

Managing Queues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30923.2 Collector. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .311

Setting Up Queues and Collectors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315Managing Customer Collectors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317Managing Clearing Collectors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319

23.3 Direct Clearing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32223.4 Assign Payment Items to Collector/Queue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32323.5 Close Collector/Queue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32523.6 Final Processing (Collectors/Queues). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32723.7 Account Management Proxy (FS-PE-AMP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329

Posting Simulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331Posting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333Reservation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .334Deletion of Reservation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .335

23.8 Alternative Clearing Scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336

24 User Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33724.1 Payment Order. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337

Edit Payment Orders (Expert). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338Create Payment (SAP Fiori). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347Create Payment Order (SAPUI5). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349Manage Payments (SAP Fiori). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .350Manage Waiting Payments (SAP Fiori). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350Display Payment Order (SAPUI5). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .351

24.2 Exception Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352Repair Payments (SAP Fiori). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352Exception Handling (SAPUI5). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354Manage Correction Rules (SAP Fiori). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354

24.3 Foreign Currency Trade Reporting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35524.4 Manage Payment Blocks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35624.5 Investigate Non-Financial Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35724.6 Management Cockpit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35824.7 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358

Setting up Additional Search Criteria for Orders and Items. . . . . . . . . . . . . . . . . . . . . . . . . . . .359

25 Periodic Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36525.1 End-of-Day Processing (FS-PE-EOD). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .367

Process Flow of End-of-Day Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368Accrual. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369Reconciliation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371

25.2 Correspondence (FS-PE-COR). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374Start Correspondence Printing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375


Display Correspondence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .378

26 Logs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38026.1 Performance Analysis in the Performance Cockpit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381

27 Release Workflow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383

28 Archiving (FS-PE-ARC). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38428.1 Maintaining Customizing Settings in Archiving Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38528.2 Archiving Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386

ILM Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387Archive Development Kit (ADK). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .388

28.3 Archiving Payment Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388Archiving Payment Orders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .391Archiving Recalls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393Archiving Request Agents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .395Archiving Collector Categories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396Archiving Service Level Agreements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397Archiving Object Lists. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398Archiving Bank File Clearing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399Archiving Value Date Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .399Archiving Routes and Clearing Agreement Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400Deleting Payment Items. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400Displaying Payment Orders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401

28.4 Archiving Logs and Documents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402Archiving Application Logs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403Archiving Change Documents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403

29 Information System (FS-PE-IS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405

30 DataSources in SAP Payment Engine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40730.1 Master Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407

Payment Order Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .407Service Level Agreement Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .408

30.2 Flow Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409Object List Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .409Payment Item Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411Payment Order Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413Payment Item Aggregated Data Extractor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416Payment Item Detailed Data Extractor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417Payment Order Aggregated Data Extractor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418Payment Order Detailed Data Extractor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420Reconciliation Hub: Payment Item Aggregated Data Extractor. . . . . . . . . . . . . . . . . . . . . . . . . 421


Content

Reconciliation Hub: Payment Item Detailed Data Extractor. . . . . . . . . . . . . . . . . . . . . . . . . . . 423Reconciliation Hub: Payment Order Aggregated Data Extractor. . . . . . . . . . . . . . . . . . . . . . . . 424Reconciliation Hub: Payment Order Detailed Data Extractor. . . . . . . . . . . . . . . . . . . . . . . . . . .426

30.3 Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428Format Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428PE Channel Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429Clearing Agreement Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .430Clearing Area Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .431Customer Agreement Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432Object List Type Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .433Payment Item Category Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434Payment Order Category Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435Payment Order Type Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436SLA Type Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437Service Level Agreement Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438Route Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439Segment Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440Transaction Type Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441


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 71].

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 329], Connection of External Systems [page 121], and Archiving (FS-PE-ARC) [page 384].

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



Payment Engine Overview

Features

Processing Functions

Payment Engine processes payments through a workflow using these functions:

● Input channelsPayment 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 257].

● Upload of referential dataPayment 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 140].

● Format conversionPayment 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 255] and File Handler Database [page 263].● 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 274], Enrichment and Validation [page 276], and Standard Settlement Instructions (SSI) [page 144].

● Routing controlPayment 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 172] and Charges [page 160].

● Clearing and settlementPayment 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 302].

● Forwarding of payment ordersPayment 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 261].

Monitoring and Control Functions

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

● Payment order managementPayment 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 338] and Recall Management [page 112].

● Exception handlingPayment 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 231].

● Other functionsPayment 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 365], Logs [page 380], and Information System [page 405].



2 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 attributes have been added:

● From ... To ... (in addition to the existing To ...)

● Cheque ID

Liquidity management New You can connect SAP Payment Engine to a liquidity management system through a proxy.

Connection to a Liquidity Management System [page 139]

Account Property New The Account Property attribute is available.

Product New For rule sets, the new attribute Product is available.

Payment Engine (FS-PE)Changes and New Features in SAP Payment Engine 9.0 SP01 PUBLIC 11

Charges - Differentia-tion Categories

Changed In addition to the existing differentiation categories, the following new differentiation categories are available:

● D30 - Product● D31 - Product

Group● D32 - Instruction

Code● D33 - Currency

Group● D34 - Country

Group (Recipient)

● D35 - Country (Recipient)

● D36 - Account Type

Charges [page 160]

Charges - Event-Driven Charges

Changed Event-driven charges are no longer managed separately. Now both transaction charges and event-driven charges are managed by charge processes.

Charges [page 160]

Clearing Agreement - Charges

Changed Charges are no longer managed under a clearing agreement. Charges are now managed under a service level agreement.

Charges [page 160]

Routing Changed In addition to the existing categories for determining a clearing route, a certain percentage of payment items can now be directed to another clearing route.


Changes and New Features in SAP Payment Engine 9.0 SP01

Value date agreement Changed The calendars of all involved countries of an FX transaction can be considered to calculate the value date agreement.

Value Date Agreement [page 211]

Service level agreement (SLA)

Changed A new hierarchy level has been introduced: The customer group SLA is available as a new type of SLA.

Service Level Agreement [page 223]

The field currency has been added to SLA conditions

New The conditions and restrictions that apply to SLAs can now also include a currency check.


SLA, foreign exchange (FX)

Changed A new tab page is 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 AdjustmentYou can now define a spread factor (instead of percentage) in the rule set.

● FX Country Equivalent

These new functions replace the existing conversion maintenance. You can migrate the existing currency exchange table by using report /PE1/R_MIGRATION_FX_SLA to the new rule sets.



SLA, correspondence Changed A new tab page is available to define correspondence settings for SLAs. A new rule set is available to flexibly control correspondence.


SLA determination based on business partner (BP) IDs

New The system can determine the relevant SLA also based on business partner IDs. To identify the relevant customer SLA, customer 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 existing account information. This reduces the effort for maintaining accounts in the SLA.


Converter Changed The following formats have been added to the converters:

● DTAZV (inbound only)

● Eurogiro

File Handler (FS-PE-FH) [page 255]

New separation criterion Eurogiro for collections

New When you set up collectors, you can now also use the Eurogiro product code and the charge category as a separation criteria.

Setting Up Queues and Collectors [page 307]

New Eurogiro format New The Eurogiro now supports format MT910 in the incoming channel.

Eurogiro [page 271]



Clearing account Changed In addition to the existing bank file clearing, a clearing account can now also be determined via the business partner in an SLA.



Enrichment and validation

New New enrichment and validation checks have been added:

● Admissibility of Codewords and Instruction Keys

● STP Capability● Configurable

Correspondence Types

● Business Partners

● Duplicate Submission

● 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 Currency Trade Reporting

● Right of disposal:If the sender of the transaction message is differ-ent from the account holder, the system checks if the sender has a right of disposal for the clearing account.You can use the Customizing activity Maintain Check Rules for Business Partner Relationships to define the right of

Enrichment and Validation (FS-PE-EV) [page 276]

Configurable Correspondence Types: Correspondence (FS-PE-COR) [page 374]

Business Partners: Service Level Agreement [page 223]



disposal in Customizing for Payment Engine under

Payment Item

Payment Item Enrichment and

Validation .

Embargo check in outgoing E&V check

New The embargo check can now be config-ured for incoming or outgoing enrichment and validation (E&V) check sets.

Embargo Check [page 298]

SAP Fiori apps New The following SAP Fiori apps are available:

● Create Payment● Manage

Payments● Manage Waiting

Payments● Repair Payments● Manage Payment

Blocks● Foreign Exchange

Trade Reporting● Release (My

Inbox)

User Interface [page 337]

UI enhancements for rate calculation

New Rate calculation features within foreign payment transactions have been enhanced

Foreign Exchange Rates [page 90]

Reservation mechanism in Repair Payments app

New You can now reserve payment orders and payment items displayed in the Repair Payment app. Orders/items reserved by you cannot be processed by others, unless they actively remove the reservation.

Repair Payments (SAP Fiori) [page 352]


Reservation mechanism in Release My Inbox app

New You can now reserve work itemsin the master/detail variant of 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 automatically reserves the item for the user.

Release [page 358]

Correspondence types

New You can use the following new correspondence 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.



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

● UI○ Maintenance

Exception Handling Errors to be ignored

○ Development

● Country Specific Settings○ Maintain

Country-Specific Processing Attributes

○ Germany● Basic Settings

○ Local System Management System

○ Product Definition

○ Charges○ Assign

Condition Types to Products

○ Determine Item Charge Amount Limits

○ Determine Trivial Minimum Limits

See Customizing documentation


○ Foreign Exchange

● Request Agent

● Referential

Data Release of Embargo/

Crisis● File Handler

○ File Handler Exception Handling

○ SWIFT Format

ConverterDetermine External Charge Informatio

n○ Eurogiro

Envelope Format Converter

● XML Converter

Generic Mapping Based

on Tag Paths

● Payment

Order SLAAssign Account Product to Customer

Segment

● Payment

Order Payment Order Enrichment

and ValidationCheck Specific

Configuration○ Maintain

Rules for Risk Scoring



○ 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 Relationships

○ Define Custom Code for Country

○ Field Validation and Routines

Account Routine and E&V Conversio

n○ STP

Relevance

● Routing

ControlBusiness Add-Ins

(BAdIs)○ Determinatio

n of Next Institution


○ Clearing System Identification

● Clearing○ Maintain

Rules for Posting Simulation

○ Maintain Rules for Reservation Process

○ Configuration for Processes○ Define

Process Symbol

○ Maintain Process-Dependent Accounts

● Posting

InterfacesAccount Management

Systems PE

Account Type

● Exception

Control Define Response Types

Response Types: Payment

Order○ Define

Reaction Types for Outgoing Order - Failed Item processing



○ Define Response Types for Release Workflow

● Exception

Control Define Response Types

Response Types: Payment

ItemReactions for Outgoing

ProcessesDefine Response Type to Exclude Items from Outgoing

Orders

● ToolsCorrespondence

Assign Correspondence Synchronization

Type





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 account system.

Charges request control at SLA level

New You can now set charge request control parameters in the SLA.

You can choose beween the following options:

● ' ' - Charge request type according to account type (for loro accounts a charge advice, for nostro accounts a charge request)

● 01 - Force charge advice (an MT190 is created)

● 02 - Force charge Request (an MT191 is created)

● 03 - No charge request is created

To set this parameter, go to the Charges tab in the SLA and select the Charge Processing rule set in question. Here you can specify the relevant Charge Request Option.

Charge type adjustment New The revised Directive on Payment Services (PSD2) allows only charge option Share (SHA) in SEPA payments. For this reason, a new E&V check has been introduced to replace the charge type automatically.

The cross item check 71 "Charge Type Adjustment" implements this functionality.

The replacement takes place only for customer initiated payments inside SEPA countries.




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 following 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.

Duplicate check New You can now define which fields should be taken into account when checking for duplicate entries. You do this by defining a Duplicate Check Group, which you assign in Customizing at order type and channel level.

See Customizing documen

tation under Payment

Engine Payment OrderPayment Order Enrichment

and Validation Check

Specific ConfigurationMaintain Field Set for

Duplicate Check V3 ;

Separation of technical queues

New Technical queues can now be separated by payment item category.

See Customizing documen

tation under Payment

Engine Clearing Specify Collection Criteria for

Technical Queues

UI - Creating private templates

New You can now mark templates for creating, managing, or repairing payment orders as private.

Private templates are visible to the user that created them. They cannot be changed or deleted by other users.

UI - Customizing New For the SAP Fiori app My Inbox you can add additional search criteria at order and at item level, which can be used as criteria to filter orders and items within the App.

Setting up Additional Search Criteria for Orders and Items [page 359]



UI - New configuration options for selection of format/medium/channel

New You can now specify on a more detailed level which format/medium/channel is sest for an order that is created through the UI.

As a result, you can create different Fiori tiles for different format/medium/channel combinations.

When searching for the correct format/medium/channel combination, the system checks the following Customizing table entries in the following sequence:

1. Payment Engine File

Handler Basic Settings

Maintain Converter2. Depending on whether the pay

ment is at order or at item level:

○ Payment Engine UIMap Default Values to Metaformat for Payment

Orders

○ Payment Engine UIMap Default Values to Metaformat for Payment

Items

3. Payment Engine

Reconciliation Assign Reconciliation Units to Converter

Attributes

As soon as a format/medium/channel 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.

See:

● Customizing documentation

● Determining Format/Medium/Channel by Reconciliation Units [page 348]




EPC inbound converter New New EPC inbound converters for customer initiated payments have been implemented.

The message types for the relevant converters are as follows:

● /EPC_CT_R17_PAIN.001.001.03 EPC Customer Credit Transfer Initiation - Rulebook 2017

● /EPC_CORE_R17_PAIN.008.001.02 EPC Core Customer Direct Debit Initiation - Rulebook 2017

● /EPC_B2B_R17_PAIN.008.001.02 EPC B2B Customer Direct Debit Initiation - Rulebook 2017

GBIC inbound converter New New GBIC inbound converters for customer initiated payments have been implemented. They follow version 3.1 of the rulebook published by the German Banking Industry Committee.

The message types for the relevant converters are as follows:

● /DK_CT_R17_PAIN.001.001.03 Customer Credit Transfer DK 3.1 - 2017

● /DK_DD_R17_PAIN.008.001.02 Customer Direct Debit DK 3.1 – 2017

● /DK_CAMT.055.001.05 Customer Payment Cancellation Request - DK 3.1 – 2017

● /DK_R17_CONTAINER.NNN.001.02 Container DK 3.1 - 2017

Bundesbank cheque directory

New The upload report for referential data has been extended by the cheque directory of the German Bundesbank.

In transaction /PE1/UPLOAD_RD choose data model CHQ and data provider BUB to import the Bundesbank cheque directory.





Charges: Maintaining condition groups from the SLA

New You can now maintain condition 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 (transaction /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 conditions groups or change the existing one.

6. Save your changes.




Rule Sets for Foreign Exchange Predefined Rates

New You now have the option of defining multiple rules for checking predefined foreign exchange rates per SLA.

Per rule, you can define the following:

● What criteria needs to be met for the rule to apply (For example, 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 predefined 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.

For details on the check settings, see the field documentation in the rule set.



○ Specify if a predefined rate is allowed, and if so, whether it needs to be checked.

○ If applicable: Enter the percentage and/or spread factor to check against.

5. Save your entries.

Maintaining Converter Attribute Code Page

New You can now also define a code page as an attribute to be used by the File Handler to handle incoming and outgoing files.

You can add this attribute in Custom

izing under Payment Engine File

Handler Basic Settings Maintain

Converter Attributes .






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

Eurogiro [page 271]

SWIFT standard outgoing channel

Changed SWIFT outgoing channel (category 1 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 account information in the swift tag option:

● Whether the account number should be taken over into the account 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 coding are used;

Correction Rules New 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.

Correction Rules [page 236]



FX Country Conversion New You can define at SLA level, that the transaction currency is converted into the destination country currency. Here are examples of how to configure the scenarios::

● For bank payments, the common 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 entire order (including all items (for example, ORP, fee)) is converted into the destination country 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 charge determination

New You can specify for SLA rule sets 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 the following objects by code words.

● execution confirmation● incoming advice note● liquidity advice note

Start Correspondence Printing [page 375]

Application Log New Log entries that are generated through simulation runs are now listed in separate simulation log blocks.




Internal Collectors Changed The criteria for internal collectors (ordering party or ordering recipient item) now take into account the account currency as well as the transaction currency.

Interbank Charges Changed Interbank charges for outgoing payments for banks via clearing systems or SWIFT are now determined as follows:

In incoming enrichment and validation checks, the BIC of the external recipient item is used to try to determine a service level agreement (SLA). SLA hierarchy levels are also taken into account. The charge from the inter-bank charge process is calculated 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 created in SAP Fiori app Create Payment Order and remain in status draft for a predefined number of days (residence time) can be deleted on a regular 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 have been added in Customizing for Payment Engine:

● Exception Control Basic Settings for Exception Handling

Automatic Postprocessing

(Learning)

● File Handler SWIFT Format

Converter Define Customer

Instruction Code

See Customizing documentation





Payment regulation release validity customizing

New A new customizing is available, where you can define the validity of a payment regulation release using a start date and time:

Payment Engine File Handler

XML Converter DevelopmentMaintain 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)




Legal changes according to the SEPA Rulebook 2018

New New XSD schemas are available according to the SEPA Rulebook 2018 changes, which is valid from 18th November 2018. The implemented changes are compatible with the following 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_$SCTCCFBLKCREDTRF

● /EBA_CT_R18_$SCTCVFBLKCREDTRF

● /EBA_CT_R18_$SCTICFBLKCREDTRF

● /EBA_CT_R18_$SCTPCFBLKCREDTRF

● /EBA_CT_R18_$SCTSCFBLKCREDTRF

The following message IDs were added for the Bundesbank converters (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_$BBKCVFBLKCDTTRF

● /BUB_CT_R18_$BBKICFBLKCDTTRF

● /BUB_CT_R18_$BBKSCFBLKCDTTRF

New converter implementations were created for the following message IDs:

● /BUBA_CH_$BBKRSFBLKSVV● /EBA_CT_R18_PACS.028.001.01




Request for recall by the originator

New The request for recall by the originator 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 RecallAssign Recall Reasons to Recall

Groups or Types ).

Additionally, a new inbound PACS.028 (Request for Status 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 message is created.

The mapping of additional reason information 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 infostructure (/PE1/PI_AIS) has been delivered for archiving object /PE1/ORD2.

File Handler data in request agent

Changed The File Handler data in the request agent UI is now displayed with a dropdown (that is, no longer on multiple tabs).

Request Agent [page 118]



SWIFT UETR (SWIFT Standard Release 2018)

New New functionality related to the SWIFT Standards MT Release 2018 is 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 provided in the file, a new UETR is generated (according to the IETF-Standard RFC 4211 (Version 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 message 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 Customizing 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).

SWIFT Converter [page 269]




Non-live BIC New In the BIC-Directory 2018 from SWIFTRef, a new characteristic is available to determine whether the BIC is a non-live BIC. This characteristic (BIC Connection Status) is now evaluated in the Payment Engine and can be used in routing control to distinguish if the BIC of a payment item is a non-live BIC.

Referential Data Interface (FS-PE-RDI) [page 140]

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

Archiving master data New New archiving objects for master data objects are introduced:

● /PE1/BFC: Bank File Clearing

● /PE1/VA: Valuta Rulesets

● /PE1/RN: Routes and Clearing Agreements

● Archiving (FS-PE-ARC) [page 384]

● Archiving Bank File Clearing [page 399]

● Archiving Value Date Data [page 399]

● Archiving Routes and Clearing Agreement Data [page 400]

Change position of a rule in a ruleset

Changed In all ruleset you can now change the position of a rule directly by using the context menu (that is, without using drag-and-drop).

Rule Set [page 156]





Instant Payments New It is now possible to send and receive instant payments in the Payment Engine. The following entires show the functions, which were added or changed to enable this new functionality.

Additionally new message IDs were created for the instant payments 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.08

Furthermore it is now possible to use the Free Message Service (PaymentTransactionConnectorManagePaymentTransactionMessageOut) to exchange messages for the message types used in the request agent (CAMT.029, CAMT.056).

For more information on the customizing steps needed for setting up instant payments, see the IMG organiza

tional activity Payment

Engine SEPA SEPA Instant Payments

Configuration




Payment Processing based on System Date & Time

New A new attribute for the payment order type configuration was introduced. With this option the payment order is processed based on system date and time. This means the planned execution date and time is compared with the system date and time instead of with the functional date and time.

Example:

ExampleA customer submits a credit transfer where the requested execution time is (for example, 08:00 p.m. CET).

In the standard approach (without using this option) the payment order 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 processed when the requested execution time is reached during processing or with the next STP POLLER job run. This change also affects the comparison 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 recommended to also use an adequate calendar 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



tion is designed to process at any time.

Time-based Processing Monitor

New The time-based processing 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 response.

Currently you can trigger an outbound PACS.028 message for a request agent of type C1 (Interbank Payment with Confirmation Monitoring) or an outbound PACS.002 message for a request agent of type C2 (Interbank Payment with Confirma-tion).




Processing with Post-Or-Cancel Option

New For online channels a new processing attribute called Post-Or-Cancel has been introduced. This option checks whether the processing result of the whole payment order is either successful (internal items are posted) OR rejected (cancelled). If the processing 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 therefore has to be ensured that the caller gets a final response (completely processed or rejected). This new processing option helps to avoid configuration errors which lead to processing results with pending objects.

To use this option you have to main

tain 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 Exception Handling (EH) reaction for payment order rejections has to be used. You can find this new IMG activity 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 conditions for triggering the rejection more precisely to suit your business needs.

NoteThis processing option also requires some changes in the existing RFC- based Account Man



agement Proxy. If thePost-Or-Cancel setting is used, then it is also handed over to BAPI interfaces for posting in FS-AM. If a material check fails then the posting request will be rejected. In this case the response message is always E148. In order to still derive the functional rejection reason, the Payment Engine internal error ID for exception handling is derived based on the return table. This requires 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 directly.

Finally, if the Post-Or-Cancel setting is used then connection errors are not handled by switching to asynchronous processing mode. The item is handed over to EH with error ID 001000 depending on the situation for phases 000050 (posting preparation) or 000100 (posting).




Support of FS-AM Reconciliation Version 2

New In Version 2 of the reconciliation procedure, SAP Account Management (FS-AM) provides the comparison based on transfer date. You can find in FS-AM the description of this procedure 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 procedure, posting dates in Payment Engine (FS-PE) and Account Management (FS-AM) do not have to be in synch.



New Request Agent Framework (Request Agent Process Orchestration)

New A new processing framework for request agents has been created that simplifies handling and allows for more flexible extensions. This new request agent processing framework is compatible with existing functionality. Its usage depends on the implementation of the corresponding request agent type.

Request agent processing options have been simplified:

● Only one processing option "Process" is now needed (instead of the previous processing options Forward, Request and Process.

● During execution details are derived automatically by the corresponding request agent type.

Similarly, the request agent status handling has been simplified. Instead of multiple statuses for each processing option only two major status are required:

● Request agents can be processed (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 executed are determined by the corresponding 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 processing steps.

In addition, data storage has been improved in two ways:

● The request agent types allow for "typed" data. This makes the




previous "data" fields superflu-ous.

● Business data can be stored together with the executed processing steps. This allows for a flexible amount of data to be stored with the request agent.

Outgoing message generation is decoupled from implementation of specific request agent types. This approach 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 processing capabilities of the request agent have been improved. It is now possible 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 reception asynchronously. This can be usefuls, for example, if the events are received prior to the original transaction and a corresponding request agent to receive the event does not exist at the time the event is received.



New Clearing Option to Post with Posting Date from Account Management System

New A new clearing option was introduced for internal clearing agreements 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-internal 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.

NoteThe usage requires the capability in the connected Account Management System to support future dated postings. To validate and adjust the posting date according to AMS calendar means the same calendar has to be used in the clearing agreement or route as is used in the Account Management System. If this option is used, the posting date is transferred in the posting request to AMS - independent from the customizing settings.




New Option for Decoupled Posting of Clearing Items

New A new option has been introduced for external clearing agreements to always decouple the posting of clearing items from sending the outgoing payment order to the output manager. 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 Posting of Payment Items

New Usually the asynchronous poller processes payment items that belong to the same account within the same package. A new option has been introduced to transfer payment items with the same account in parallel to the account management system. It's important to mention that this option only makes sense if the corresponding account allows parallel postings (no balance checks).

With this option it is possible to achieve 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)



New Reference Date for Value Date Determination

New Previously the asynchronous poller processed payment items that belong 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 account management system. It is important to mention that this option only makes sense if the corresponding account allows parallel postings (no balance checks).

With this option it is possible to achieve 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 Processing Category

New A new payment order processing category has been introduced that allows final processing based on the response of a positive confirmation status. This processing behavior is recommended, for example, when receiving SEPA instant payments. In this case, final processing of the payment order is stalled until a positive external response has been received.




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 handler 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 together with their respective file handler 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 EOD programs

Changed In order to accelerate EOD (End of 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 orders 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.



OPM Stream Class Changed The OPM Stream Class /PE1/CL_OPM_OUTPUT_STREAM_FREE uses the synchronous web service consumer PaymentTransactionConnectorManagePaymentTransactionMessageOut 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 payload 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 errors can occur which cause the payment processing to be reverted (rolled 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 corresponding Payment Engine object (for example, the payment order), whether the payload could be sent successfully. You can define the forwarding status in the IMG activity -

Payment Engine File Handler

External Response .




Update Web Service Operation CreateOrder

Changed The operation CreateOrder from web service PaymentTransactionProcessingManagePaymentTransactionOrderIn previously mapped the XML Element <BankAccountDocumentReconciliationKeyID> into the corresponding fields of payment order reconciliation data without mapping the item reconciliation data.

With this change the mapping logic is harmonized which means that the externally provided reconciliation data in XML Element <BankAccountDocumentReconciliationKeyID> 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 Status Update

Changed Exception handling (EH) configura-tion for external status responses has been consolidated into a single new EH-process 68 - External Status Reponse. The new configuration simplifies customizing for external status responses of incoming and as well as outgoing payment orders as part of the same "process". Existing configurations of phase External Status Update" within process Outbound File Processing can be migrated by executing the corresponding migration report /PE1/R_MIG_ESR_RULESET.




Function

Type of Change Description More Information

Legal changes according to the SEPA Rulebook 2019

New New XSD schemas are available according to the changes made to the SEPA Rulebook 2019, which is valid from 18th November 2019. The implemented changes are compatible with the following 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



Function


● /EBA_DD_R19_PACS.002.001.03S2● /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 converters (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


Function


● /DK_R19_PAIN.002.001.03● /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)



Function


Legal changes according to the SWIFT Standards Release 2019

Change

The SWIFT UETR (Unique End-to-End Transaction Reference) is now used in the following SWIFT converters:

● MTn90 (Message ID /SWIFT_MTN90)






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

The inbound MTnXX converters map this field into the File Handler data.

The outbound converters map this field through one of the following methods:

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

2. UETR is copied from the original message3. 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



Function


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 Converters (Instant Payments)

New The following XSD schemas were added for the TIPS converters:

● /TIPS_R19_ADMI.007.001.01● /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 participants 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 Provider).

NotePlease note that only a full upload is supported.

Upload of Referential Data [page 142]



Function


Address Information in CAMT.029

New Address information can now be enriched from the business 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 address 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 Management Proxy. The web service (PaymentTransactionProcessingManageBusinessPartnerOut) retrieves the address information for the business partner. This information is written into the AddtlInf XML-tags of the outbound CAMT.029 message (see the fallback implementation of BAdI /PE1/BADI_RA_ADDRESS).


Function


Different Error Codes for AM Connection Issues

New The business object Exception (database table /PE1/DB_EH_FCHCK) was extended with the attribute Differentiation Value. This new attribute has the approach to differentiate exceptions with additional information in place of duplicating existing 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 example, 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 creation (Differentiation Value = PRX002) to reject the payment order.

● For Posting Requests (Differentiation Value = PRX003), you can define for the same Error ID 001000 to retry immediately or with delay.

Exception Control (FS-PE-EH) [page 231]

DK PAIN.002 (Customer Payment Status Report)

Change

A new field (indicator) No ACCP is added in the Order Type ID customizing. If this indicator is set, then the accepted items are 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 .



Function


Updated Synchronous FSN Service

Change

The synchronous FSN web service consumer (PaymentTransactionConnectorManagePaymentTransactionMessageOut) 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 PACS.002 Instant Payment Inbound Converter

Change

In the context of SEPA Instant Payments, the transaction references (XML-Tag TxInfAndSts) should always be available in the PACS.002 message.

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 retrieved internally based on the original Message ID, if not provided 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 .




Function


Request Agent Timeout Handling

Change

The following new fields are available for the request agent time

out 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 .



Function


SEPA Investigation Processes

New An additional function is provided to enable the SEPA investigation processes.

Payment investigation messages (camt.027) and payment modification requests (camt.087) allowing for value date adjustments can be triggered for payment items in Edit Payment Orders (Expert) (transaction /PE1/PO_EXPERT).

Corresponding outbound messages can be created by processing 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 (transaction /PE1/REQ_AGENT_MASS), the outbound camt.029v8 messages 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 .

Request Agent [page 118]


Function


Universal Confir-mations for MT103

New The function to support payment confirmation for SWIFT MT103 messages is provided. In detail, an outbound MT199 FIN Universal Confirmations of MT103 messages can be sent to the gpi tracker.

The new check (check Id 105) needs to be added to the corresponding E&V check set. When finalizing the payment, a request 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 .

SAP Notes 2898954

and 2911886

SWIFT MX Converters

New The SWIFT MX converters are provided according to the Cross-border Payments and Reporting Plus (CBPR+) specifications based on SR 2019 ISO 20022 messages. In detail, the following converters are delivered:

● pacs.008 (FI to FI Customer Credit Transfer)● pacs.009 (Financial Institution Credit Transfer)● pacs.004 (Payment Return)


SAP Note 2918904

TARGET2 Converters

New The TARGET2 converters are provided according to the RTGS (T2) specifications based on V09 ISO 20022 messages. In detail, the following converters are delivered:

● pacs.008 (FI to FI Customer Credit Transfer)● pacs.009 (Financial Institution Credit Transfer)● pacs.004 (Payment Return)

XML Converter Framework [page 265]

SAP Note 2895417



http://help.sap.com/disclaimer?site=https://launchpad.support.sap.com/#/notes/2898954




Function


SWIFT Standards MT Release 2020

Change

Regulatory SWIFT changes for the SWIFT MT Release 2020 are 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 option for fields 50 and 59

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

SAP Note 2898954



10 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.

NoteThis 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 69].

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 255].

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.

NoteAny 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 263] and Input Manager [page 257].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 274] and Enrichment and Validation [page 276].

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


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 172].

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 302].

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.

NoteThe 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.

NoteFrom 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.

NoteAll 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 67

For more information, see Output Manager [page 261].12. Output Manager transfers the payment order to the relevant outgoing channel in the target format.


End-to-End Payment Processing

11 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 223] and Managing Service Level Agreements [page 226].

● You have assigned charges to service level agreements and clearing agreements. For more information, see Charges [page 160].

● You have uploaded and managed standard settlement instructions. For more information, see Upload of Referential Data (SSI) [page 146].

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 69

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 144].

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.

NoteIf 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 231].

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)

NoteIf 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 160].

NoteIf 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.

NoteThis 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.


Basic Cross-Border STP

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

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

Route Processing

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

NoteThe 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 172].

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.

NoteAny 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 71]

11.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).


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 66].

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 140] and Standard Settlement Instructions (SSI) [page 144].

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 160].

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 processingRouting of a payment item not only to the beneficiary but also to an intermediary institution in the transaction chain

NoteThe 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


Basic Cross-Border STP

For more information, see Basic Cross-Border STP [page 69].


12 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 74]● Recall of SEPA Credit Transfers [page 81]● Cash Pooling with Request for Transfer [page 89]● Foreign Exchange (FX) [page 250]

12.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 Processes


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.

NoteThe 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 255].

● 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 112].

● 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 134].

● 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 302].

● 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 186] and Setting Up Queues and Collectors [page 307].

More Information

Active Request for Cancellation [page 76]

Passive Request for Cancellation [page 79]

Payment Engine (FS-PE)Payment Processes PUBLIC 75

12.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 ManagementMaintain 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 an


Payment Processes

entire payment order, you must create a recall for each recipient item manually. For more information about creating recalls, see Recall Management [page 112].

NoteYou 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.

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

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 134].

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.

NoteYou 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.


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 134].

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 Processes

More Information

Request for Cancellation [page 74]

Passive Request for Cancellation [page 79]

12.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 ManagementMaintain 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 .


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 257].

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 255].


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 115].

NoteThe 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 134].

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 172].8. The system posts a clearing item to the clearing account of the clearing house.

More Information

Request for Cancellation [page 74]

Active Request for Cancellation [page 76]


Payment Processes

12.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 82].

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

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

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


● Request Agent Determine Routing for Third-Party CAMT Messages .

● Request Agent Business Add-Ins (BAdIs)

12.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


Payment Processes

period has elapsed, 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 – 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 EnginePeriodic Processing Processes Request Agent Mass Processing to schedule this in end-of-day processing, with the action Forward.)


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 251].


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.


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 118].

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


12.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 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 74].○ 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.


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 118].

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



Payment Processes

12.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)


12.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 ControlYou 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 componentYou 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 250]Foreign Currency Trade Reporting [page 355]

12.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 tablesFor 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 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.


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 355]

12.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 278]


Alternative Clearing Scenarios [page 336]


Payment Processes

12.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 123]). The switch can either consume the business services and directly create and process a payment order (also see Payment Transaction Order In [page 125]) or recall (see Action Payment Transaction Order [page 128]). Alternatively, the payment engine connector (see Payment Engine Connector [page 131]) 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 270]).

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

More Information

Authorization Request Processing [page 94]

Financial Request Processing [page 95]

Authorization Reversal [page 96]


12.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 274]) 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 268]


Payment Processes

12.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





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



12.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 110]). 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 231].



Activities



More Information


Recall [page 110]


Payment Processes

13 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 367].

● 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.

● AuthorizationFor 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 dataParticularly, routes, clearing agreements, and their rule sets, as well as exception control rule sets with their response types

● Transaction dataPayment orders and payment items

● Customizing dataParticularly, 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 SettingsOrganization Define Clearing Area .

Payment Engine (FS-PE)Clearing Area PUBLIC 97

Structure

The following main attributes specify a clearing area:

● General calendarThis calendar determines the processing days at clearing-area level.

NoteIn 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 currencyThis 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 SystemsDefine SAP AM Bank Posting Area . For more information about the accrual and reconciliation processes, see Accrual [page 369] and Reconciliation [page 371].


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 99

Example 2: Modeling of clearing areas


Clearing Area

14 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 255].

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 338].

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 276].

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 areaSpecifies the legally independent organizational unit where a payment order was created or imported from.

● Payment order numberDetermined 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 101

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 340].

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 106].

Payment orders can represent:

● Internal paymentsA 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 paymentsA 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 383] and Release Object ORDER (Payment Order) [page 103].

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.

ExampleIncoming payment order

● One ordering party to many recipientsSalary payment by a company: The ordering party is a company, the recipients are the employees.

● One ordering party to one recipientSimple 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 223].


Payment Order

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

ExampleOutgoing 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 172] and Clearing Processing (FS-PE-CP) [page 302].

14.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


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:

● DisplayChoosing this pushbutton brings you to the dialog transaction Edit Payment Orders (Expert).

● ChangeChoosing 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.

● ReleaseThis 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 Payment Order

Release Status Release Activity Status of the Payment Order

Release Status

105, 110, or 170 For Release Processing Depending on the settings: 117, 120, 128, 170, 311

Released


Payment Order

Editing the payment order:




Release Status

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

Released

● RejectChoosing 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:




Release Status

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

Editing the payment order:




Release Status

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

Rejected

More Information

Payment Order [page 101]

Edit Payment Orders (Expert) [page 338]


15 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 255].

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 ManagementEdit Payment Orders (Expert) (transaction /PE1/PO_EXPERT). For more information, see Edit Payment Orders (Expert) [page 338].

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 ProcessesExecute 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:

● CollectedThe payment item has already been assigned to an account, but is not yet included in the account balance.

● QueuedThe payment item is waiting to be manually released or is scheduled to be processed later.

● PostedThe payment item has been posted to an internal account.

● In PostprocessingThe 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 Item

Structure

Payment items are uniquely defined by the following parameters:

● Clearing areaSpecifies the legally independent organizational unit where a payment item was created or imported from.

● Payment item numberDetermined 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 EnginePeriodic 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 340].

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 276].

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 383] and Release Object POITEM (Payment Item) [page 108].

Payment Engine (FS-PE)Payment Item PUBLIC 107

15.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


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


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.


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 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.

● DisplayChoosing this pushbutton opens the dialog transaction Edit Payment Orders (Expert).

● ChangeChoosing 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 documentsChoosing this pushbutton opens the dialog transaction Edit Payment Orders (Expert) with dialog box Display Change Documents of the payment item.

● ReleaseThis method in the Business Workplace can change the status and release status of the payment item as follows:Editing the payment item:


Status of the Payment Item

Release Status Release Activity Status of the Payment Item

Release Status

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

More Information

Payment Item [page 106]


Payment Engine (FS-PE)Payment Item PUBLIC 109

16 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:

● ManualFor recalls that you create manually

● SWIFTFor recalls converted from the SWIFT message format

● SDD RecallFor recalls converted from a request to cancel a SEPA Direct Debit (SDD) transactionFor more information about manual and SWIFT recalls, see Recall Processing [page 115]. For more information about requests for cancellation, see Request for Cancellation [page 74].

● Active SCT RecallWhen 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 82].

● Passive SCT RecallWhen 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 86].

● Electronic RecallFor 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 82].

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 .


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 112].

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 – matching 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 legal and archiving reasons this status is different than the Inactive status and is called Legally Active.

Payment Engine (FS-PE)Recall PUBLIC 111

16.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 276].

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,


Recall

Matched, Legally Active or Inactive. You can display these according to data source, by choosing ExtrasChange 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 66].

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 items are to be recalled

/PE1/BAPI_RECALL_PROCESS


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 231].

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.

NoteThe 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.

NoteYou 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 Recallsfrom the SAP Easy Access screen.

More Information

Recall [page 110]


Recall

Recall Processing [page 115]

Active Recall of SEPA Credit Transfers [page 82]

Passive Recall of SEPA Credit Transfers [page 86]

16.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 112].

You can use recall management only for payment orders and recipient items that have not been finally processed.

Process

NoteYou 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).


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.

NoteIn 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 231].

More Information

For more information, see the following documentation:

● Recall [page 110]● Recall Management [page 112]● Enrichment and Validation [page 276]● Active Recall of SEPA Credit Transfers [page 82]● Passive Recall of SEPA Credit Transfers [page 86]

16.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


Recall


You make the settings for release object RECALL in Customizing for Payment Engine under Recall Management Release for Recalls in the following Customizing activities:


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 110].


17 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.


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 119

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 82]● Passive Recall of SEPA Credit Transfers [page 86]● Archiving Object /PE1/RAG [page 395]● For more information about Customizing settings related to the request agent, see Customizing for

Payment Engine (FS-PE), under Request Agent .


Request Agent

18 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 123].

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 255].

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 121

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).

NotePayment 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 134].○ Connection to an embargo or other system through an API

For more information, see Connection to an Embargo System [page 138].○ Connections to other systems and customer-specific or country-specific extensions by using these

BAdIs as models2. You implement your specific methods using the BAdI models.3. You carry out applicable activities in Customizing for Payment Engine.


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

18.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.


More Information

18.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 160]



18.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 126]● Payment Transaction Order Event Out [page 130]

18.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


● PaymentTransactionOrderActionIn containing the operation for order cancellation and transaction recall

More Information

Payment Transaction Order business object

Payment Transaction Processing processing component

18.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 276]). The validation result is returned synchronously.

Technical Data

Entity Type Service Operation

Release State Not defined

Technical Name PaymentTransactionProcessingManagePaymentTransactionOrderIn

Mode Synchronous

Idempotency Not applicable

Change/Update Behavior Not applicable


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 HandlerFinancial 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

274].○ Validation: The created order is validated according to the application component E&V (Enrichment

and Validation (FS-PE-EV) [page 276].



○ 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 274].

○ Immediate Processing: The order is processed synchronously according to Payment Processing (FS-PE-POP) [page 274] 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


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.


18.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



Technical Name PaymentTransactionProcessingPaymentTransactionOrderActionIn

Mode Synchronous




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


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 .




More Information

For more information, see the Payment Transaction Order business object.

18.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



Technical Name PaymentTransactionProcessingQueryPaymentTransactionOrderIn

Mode Synchronous




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


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 BAdIs for Enterprise Services BAdIs


for Business Object PaymentTransactionOrder BAdI for PaymentTransactionProcessingQueryPaymentTransactionOrderIn .


More Information

For more information, see the Payment Transaction Order business object.

18.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



Technical Name PaymentTransactionProcessingPaymentTransactionOrderEventOut

Mode Synchronous




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.



Message Types

● PaymentTransactionOrderFSStatusBulkNotification

18.1.2.3 Payment Transaction Order In

New Service 9.0

18.1.2.4 Payment Transaction Order Out

18.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 132]

Payment Connector Out [page 133]



18.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 HandlerFinancial 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 118].

● 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



Technical Name PaymentTransactionProcessingManagePaymentTransactionOrderIn

Mode Synchronous

Idempotency Applicable


Direction Inbound

BAdI /PE1/BADI_MSG_INTV1




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 93]).

Related Operation

The CreateMessage inbound operation receives a request from a sending system to import a free format message.

Message Types

● PaymentTransactionMessageFSCreateRequest● PaymentTransactionMessageFSCreateConfirmation


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.

18.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



Technical Name PaymentTransactionConnectorManagePaymentTransactionMessageOut

Mode Synchronous




Direction Outgoing

BAdI /PE1/BN__OUT_CRT_FREE_MSG


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 .


18.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.



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.

NoteYou 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 123].

Integration of Account Management (FS-AM)

For information, see Account Management Proxy (FS-PE-AMP) [page 329].

Integration of Bank Customer Accounts (IS-B-BCA)


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 329].

More Information

Clearing Processing (FS-PE-CP) [page 302]

18.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.○ 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.

18.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.○ The file import generates a payment order that is processed in Payment Engine.


● Transfer payment information from Payment Engine to CML1. 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 .

18.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 OrderBusiness 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○ Maintain for Embargo Response Code Mapping



Features

NoteYou 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 298]

For more information about security, see SAP Service Marketplace at https://service.sap.com/securityguideIndustry Scenario Security Guides Security Guide for SAP Payment Engine

18.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 ValidationCheck 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.


http://help.sap.com/disclaimer?site=https%3A%2F%2Fservice.sap.com%2Fsecurityguide

19 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


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 fileOn 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 142]○ Upload of Referential Data (SSI) [page 146]○ Upload of Referential Data (Bank Master Data) [page 149]

● 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 151].● Display business partners


Referential Data Interface (FS-PE-RDI)

On the SAP Easy Access screen, choose Payment Engine Referential Data Bank Master DataDisplay 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

NoteThe 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 141]

Standard Settlement Instructions (SSI) [page 144]

Bank Master Data [page 148]

19.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 141

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 142]. 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 DataRouting 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 172]

19.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.



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 .

NoteRouting 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 141].

Activities

● To access this report, on the SAP Easy Access screen, choose Payment Engine Referential DataUpload 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 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


19.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.



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 146]. 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 276]. 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 231].

More Information



19.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


File location


Output



The uploaded data is mapped to the database internal data structure. For information about the data structure, see Standard Settlement Instructions [page 144].

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



19.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 149]. You can access the stored data on the SAP Easy Access screen by choosing



Payment Engine Referential Data Bank Master Data Manage Bank Master Data (transaction /PE1/MN_BNKSTRUCT).

NoteWhen 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 151].

More Information


19.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


● Data provider

Upload process


File location


Output

The uploaded data is mapped to the database internal data structure. For information about the data structure, see Bank Master Data [page 148].

Activities

● To access this report, on the SAP Easy Access screen, choose Payment Engine Referential DataUpload 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.



More Information


19.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 149].

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


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.

NoteWhen 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 DataBank Master Data Display Business Partners (transaction /PECROSS/BP_BANK).

More Information

Bank Master Data [page 148]



19.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.

NoteThis 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

RecommendationYou 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● 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 284]

Recipient Item Checks [page 287]



20 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 160].

● 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 169].

● 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 276] and Service Level Agreement [page 223].

● 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 172].

● 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 302].

● 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 231].

Features

● Master data objects and business rules are separated at clearing-area level. For more information, see Clearing Area [page 97].

● Master data objects are linked to each payment through the use of rule sets. For more information, see Rule Set [page 156].

Payment Engine (FS-PE)Master Data PUBLIC 155

● 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 184]

20.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 AgreementBusiness 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 157].

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.


Master Data

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 169]




20.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.

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 AgreementsManage Service Level Agreements Submission Data

● Rule sets for foreign exchange conditions:On the SAP Easy Access screen, choose Payment Engine Master Data Service Level AgreementsManage Service Level Agreements Foreign Exchange

● Rule sets for charge conditions:On the SAP Easy Access screen, choose Payment Engine Master Data Service Level AgreementsManage 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.

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.


Master Data

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 156].

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 operatorsCompares a predefined value of an attribute in a rule with the current value of a given payment item or payment order.

● Interval checkChecks whether the given attribute value lies within the interval that can be defined with the help of “from” and “to” values.

● Pattern matchingIs 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 operatorsCan 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 checkIs 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

A rule set for routes contains the following rules:

Sequence Transaction Code

Payment Order Priority

BIC Currency Amount Further Attributes

Route

1 Normal XXDEFF* EUR > 100.000 None ROUTE_1


Sequence Transaction Code


BIC Currency Amount Further Attributes

Route

2 5001 Normal ++++DE* EUR 100.000 – 1.000.000

None ROUTE_2

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.

20.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). 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.


Master Data

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 ProcessingIn 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.

NoteFor more information on the application IDs used for charges, see below.

● Charge BearerIn 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.

NoteIf 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 AccountIn 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 .

NoteIf 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.

By assigning specific values to these categories, you restrict the use of a condition to objects that meet this selection criteria.


Master Data

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 institutions;

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 provided 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 example), you can use this process to deduct a charge;

011 Charge for Recall Processing Determines charges during recall processing;

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 postprocessing and a user has to manually correct the transaction details, you can use this process to deduct a charge;

080 Charge Balancing Process This is a technical charge process that is triggered by the system in order to balance the charge amount.

Examples:

● The charge amount is to be neglected due to threshold customizing;

● The charge amount is higher than the transaction amount;


Master Data


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.

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;


Application System Used For Can be Used in Charge Process ID

CHRG_PO Charge posting via payment order All processes except 81;

CHRG_REQ Interbank charge request 081 (to request charge from the sending 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 partyIn 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 166]Differentiation Categories [page 168]Basic Cross-Border STP [page 69]

20.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.

NoteThe 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


Master Data

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.

NoteIf 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


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


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 160]Differentiation Categories [page 168]Service Level Agreement [page 223]

20.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

D04 Payment Order Type

D05 STP Capability

D07 Recall Type

D08 Return Reason

D09 Recall Group

D10 Number Recipient Items

D12 Medium

D13 Channel


Master Data

Description

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 SettingsCharges Define Differentiation Categories .

To assign condition categories to them in Customizing, go to Payment Engine Basic Settings ChargesAssign Condition Categories to Differentiation Categories .

More Information

Charges [page 160]

Editing Charge Conditions [page 166]

20.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.

NoteYou 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 276].

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.

ExampleAn 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 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


Master Data

● Account number● Account currency● IBAN● Account holder

Indicator for separate provision of cover

NoteYou 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

Alternative

NoteAnother 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 281].

More Information

Manage Bank File Clearing Accounts [page 172]


20.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 SettingsOrganization Define Clearing Area .

● You have defined payment order types in Customizing for Payment Engine by choosing Payment OrderDefine Payment Order Types .

● You have defined clearing system IDs in Customizing for Payment Engine by choosing File HandlerBasic 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 280] and Payment Order Checks [page 281].

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).

More Information


20.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


Master Data

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:

● RouteFor more information, see Route [page 174].

● Clearing agreementFor more information, see Clearing Agreement [page 186].

● Customer agreementFor more information, see Customer Agreement [page 198].

● Valute date agreementFor more information, see Value Date Agreement [page 211].

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.

For more information about the connected process and components, see:

● Payment Processing (FS-PE-POP) [page 274]● Enrichment and Validation [page 276]● Clearing Processing (FS-PE-CP) [page 302]

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 231].

Rule SetsA 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 383].

20.4.1 Route

Definition

An object that indicates whether a payment item is to be posted internally or externally:

● InternallyThe 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.

● ExternallyThe 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.


Master Data

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 383].

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 231]. 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 177] and Managing Route Rules [page 179].

Structure

Route Screen

The route screen is organized in the following screen areas:

● Search areaYou 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 treeDisplays existing routes, clearing agreements, and customer agreements in a hierarchical structure.

● Business objectDisplays details about the selected route, clearing agreement, or customer agreement organized on tab pages.

● RulesDisplays 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 statusA route can have the following route statuses:○ Active○ Inactive○ Flagged for deletion

● Internal/external indicatorSpecifies 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 ordersIndicates 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 boxIndicates 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 211].


Master Data

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 156].

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.


More Information

Clearing Agreement [page 186]

20.4.1.1 Managing Route Rule Sets

Use

You can manage route rule sets as follows:

● Create a route rule setYou 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 setYou 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 setYou can delete a route rule set by deleting all rules in the rule set.

● Display a route rule setYou 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 ControlRelease 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.

NoteYou 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.

2. Enter data as required.3. Save the object and trigger the release process by choosing the Release pushbutton.

NoteYou can process only objects with Released status.

Creating Route Rule

Create a route rule.

For more information, see Managing Route Rules [page 179].

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 174] under Structure.

NoteYou can show or hide the rule set by choosing the Set of Rules pushbutton.


Master Data

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.

NoteYou 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.


2. In change mode, choose the Delete Rule Set pushbutton to set all rules in the rule set to Flagged for Deletion.

NoteWhen you delete a rule set, the system also deletes all rules associated with the rule set.


NoteThe object is actually deleted when it reaches the Released status.

Displaying Route Rule Sets

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.

20.4.1.2 Managing Route Rules

Use

You can manage route rules as follows:

● Create a route ruleYou can create a rule that is used during routing process to determine the route.

● Change a route ruleYou 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 ruleYou can delete a route rule by changing a route.


● Display a route ruleYou 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 ControlRelease 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:


Procedure



Creating Route Rules

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 174] under Structure.

NoteYou 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.



Master Data

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.


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.


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.

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.


3. In the rules screen area, choose the rule that you want to delete and choose .The rule is selected for deletion.


NoteYou 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.



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.

20.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


You make the settings for release object ROUTE in Customizing for Payment Engine under Routing ControlRelease Route and Rule Set in the following Customizing activities:


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.


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.


Master Data

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 184].

● DisplayChoosing this pushbutton brings you to the dialog transaction Manage Routes and Clearing Agreements.

● ChangeChoosing 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 documentsChoosing this pushbutton opens the dialog transaction Manage Routes and Clearing Agreements with dialog box Display Change Documents of the route.

● ReleaseThis method in the Business Workplace can change the status and release status of the route as follows:Editing the route:


Status of the Route Release Status Status of the Route Release Status

Inactive For Release Active Released

● RejectChoosing 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:


Status of the Route Release Status Status of the Route Release Status

Inactive For Release Active In Process

More Information

Route [page 174]


20.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

The following graphic illustrates the possible statuses for all these objects:

Status and Release Status of a Master Data Object


Master Data

NoteTo 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 228]Release Object ROUTE (Route) [page 182]Release Object CA (Clearing Agreement) [page 195]Release Object CUSTAGR (Customer Agreement) [page 206]Release Object CAGRASS (Assignment of General Customer Agreement) [page 208]Release Object EH (Exception Control Rule Set) [page 246]Foreign Exchange (FX) [page 250]

20.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 HandlerBasic 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.

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 261].● 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 118].

20.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.


Master Data

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 383].

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 231]. 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.

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 190] and Managing Clearing Agreement Rules [page 192].

Structure

Clearing Agreement Screen

The clearing agreement screen is organized in the following screen areas:

● Search areaYou 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 treeDisplays existing routes, clearing agreements, and customer agreements in a hierarchical structure.

● Business objectDisplays details about the selected route, clearing agreement, or customer agreement organized on tab pages.

● RulesDisplays 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

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.


Master Data

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 ClearingDefine and Maintain Account Symbols .

● Execution On checkboxIf 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/MarkdownSpecifies 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 fieldYou 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

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 304] and Collector [page 311].

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.



More Information

Route [page 174]

Customer Agreement [page 198]


20.4.2.1 Managing Clearing Agreement Rule Sets

Use

You can manage clearing agreement rule sets as follows:

● Create a clearing agreement rule setYou 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 setYou 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 setYou can delete a clearing agreement rule set by deleting all rules in the rule set.

● Display a clearing agreement rule setYou can display a clearing agreement rule set by displaying a clearing agreement associated with this rule set.

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 ControlRelease 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:


Procedure



Master Data


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.

NoteYou 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 192].


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 186] under Structure.


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.



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.







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.

20.4.2.2 Managing Clearing Agreement Rules

Use

You can manage clearing agreement rules as follows:

● Create a clearing agreement ruleYou can create a rule that is used during routing process to determine the clearing agreement.

● Change a clearing agreement ruleYou 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 ruleYou can delete a clearing agreement rule by changing a clearing agreement.

● Display a clearing agreement ruleYou 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 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:



Master Data

Procedure



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 186] under Structure.






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.








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.





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.




Master Data

20.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


You make the settings for release object CA in Customizing for Payment Engine under Routing ControlRelease Clearing Agreement and Rule Set in the following Customizing activities:


Channel

Dialog


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.


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 197].


● DisplayChoosing this pushbutton brings you to the dialog transaction Manage Routes and Clearing Agreements.

● ChangeChoosing 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 documentsChoosing this pushbutton opens the dialog transaction Manage Routes and Clearing Agreements with dialog box Display Change Documents of the clearing agreement.

● ReleaseThis method in the Business Workplace can change the status and release status of the clearing agreement as follows:Editing the clearing agreement:


Status of the Clearing Agreement

Release Status Status of the Clearing Agreement

Release Status


● RejectChoosing this pushbutton rejects the change of the clearing agreement.This method in the Business Workplace can change the status and release status of the clearing agreement as follows:Editing the clearing agreement:


Status of the Clearing Agreement

Release Status Status of the Clearing Agreement

Release Status


More Information



Master Data


Related Information


20.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.


Master Data

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 201] and Managing Customer Clearing Agreement Rules [page 203].

Structure

Customer Agreement Screen

The customer agreement screen is organized in the following screen areas:

● Search areaYou 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 treeDisplays existing routes, clearing agreements, customer agreements, and customer clearing agreements in a hierarchical structure.

● Business objectDisplays 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 informationContains the route ID, its description, and the release status of the route to which the customer agreement is assigned.

● Customer agreement informationContains 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 agreementThere are the following types of customer agreement:○ General customer agreement○ Specific customer agreement

● Customer agreement statusA customer agreement can have the following customer agreement statuses:○ Active○ Inactive○ Flagged for deletion

● Bank customerYou can use this field to assign a customer agreement to a specific customer.

● Valid from and valid toIndicates the validity of the customer agreement.

● Assigned Accounts tab pageYou 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 186] 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 276] and Service Level Agreement [page 223].

● 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 302].


Master Data

20.4.3.1 Managing Customer Agreement Rule Sets

Use

You can manage customer agreement rule sets as follows:

● Create a customer agreement rule setYou 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.

● Change a customer agreement rule setYou 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 setYou can delete a customer agreement rule set by deleting all rules in the rule set.

● Display a customer agreement rule setYou 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 ControlRelease 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:


Procedure



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.



Creating Customer Clearing Agreement

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.



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 198] under Structure.

3. Create a customer clearing agreement rule.For more information, see Managing Customer Clearing Agreement Rules [page 203].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.


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.



Master Data


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.






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.

20.4.3.2 Managing Customer Clearing Agreement Rules

Use

You can manage customer clearing agreement rules as follows:

● Create a customer clearing agreement ruleYou can create a rule that is used during routing process to determine the customer clearing agreement.

● Change a customer clearing agreement ruleYou 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 ruleYou can delete a customer clearing agreement rule by changing a customer clearing agreement.

● Display a customer clearing agreement ruleYou 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 ControlRelease Customer Agreements .

● You have the necessary rights to change and create a customer clearing agreement and its rules for the selected clearing area.

To display a customer clearing agreement and its rules:


Procedure



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 198] under Structure.






Changing Customer Clearing Agreement Rules


Master Data

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.







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.





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.




20.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


You make the settings for release object CUSTAGR in Customizing for Payment Engine under Routing ControlRelease Customer Agreements in the following Customizing activities:


Channel

Dialog


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.


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.


Master Data

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 209].

● DisplayThis pushbutton opens the dialog transaction Manage Routes and Clearing Agreements.

● ChangeThis 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 documentsThis pushbutton opens the dialog transaction Manage Routes and Clearing Agreements with dialog box Display Change Documents of the customer agreement.

● ReleaseThis method in the Business Workplace can change the status and release status of the customer agreement as follows:Editing the customer agreement:


Status of the Customer Agreement

Release Status Status of the Customer Agreement

Release Status


● RejectChoosing 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:


Status of the Customer Agreement

Release Status Status of the Customer Agreement

Release Status


More Information



20.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


You make the settings for release object CAGRASS in Customizing for Payment Engine under Routing ControlRelease Customer Agreements Assignment to General Customer Agreement in the following

Customizing activities:


Channel

Dialog


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.


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.


Master Data

More Information









Related Information

Release Object SLA (Service Level Agreement) [page 228]Release Object ROUTE (Route) [page 182]Release Object CA (Clearing Agreement) [page 195]Release Object CUSTAGR (Customer Agreement) [page 206]Release Object CAGRASS (Assignment of General Customer Agreement) [page 208]


Master Data

Release Object EH (Exception Control Rule Set) [page 246]Foreign Exchange (FX) [page 250]

20.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 231]. 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.


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 214] and Managing Value Date Agreement Rules [page 217].

Structure

Value Date Agreement Screen

The value date agreement screen is organized in the following screen areas:

● Search areaYou 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 treeDisplays existing rule sets and their associated value date agreements in a hierarchical structure.

● Business objectDisplays details about the selected value date agreement organized on tab pages.

● RulesDisplays 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


Master Data

● Information about rule set for value date agreementsContains 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 informationContains the value date agreement ID, its description, and the release status of the value date agreement.

Basic Data

● Value date agreement statusA value date agreement can have the following value date agreement statuses:○ Active○ Inactive○ Flagged for deletion

● Value dating necessityYou 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 splitIndicates 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 acceptanceIndicates whether the feeder system is allowed to submit a value date to Payment Engine.

● Value date interval checkIndicates 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 boxIndicates whether the value date agreement is valid for different kinds of payment items.

● Calendar Included for Calculation group boxIndicates 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 ValueIndicates the date and time that is used as a basis for value date calculation, for example posting date or recipient item value date.

● Markup/MarkdownIndicates the time added to or subtracted from the base value.

● 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 156].

More Information

Route [page 174]


20.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 agreementYou 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 agreementYou 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 agreementYou can delete a rule set for value date agreement by deleting all rules in the rule set.

● Display a rule set for value date agreementYou can display a rule set for value date agreement by displaying a value date agreement associated with this rule set.


Master Data

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 ControlRelease 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:


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.


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.



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.You can also copy an existing value date agreement on which you base your new value date agreement.




Creating Value Date Agreement Rule

Create a value date agreement rule.

For more information, see Managing Value Date Agreement Rules [page 217].


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 211] under Structure.

NoteYou 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.



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.


2. In change mode, choose to set all rules in the rule set to Flagged for Deletion.




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.


Master Data

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.

20.4.4.2 Managing Value Date Agreement Rules

Use

You can manage value date agreement rules as follows:

● Create a value date agreement ruleYou can create a rule that is used during value dating to determine the value date.

● Change a value date agreement ruleYou 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 ruleYou can delete a value date agreement rule by changing a value date agreement.

● Display a value date agreement ruleYou 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 ControlRelease 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:


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.


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 211] under Structure.






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.



4. Make the required changes.5. You can do one of the following:




Deleting Value Date Agreement Rules


Master Data

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.





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.



20.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


You make the settings for release object VA in Customizing for Payment Engine under Routing ControlRelease Value Date Agreement and Set of Rules in the following Customizing activities:


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.


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 221].

● DisplayChoosing this pushbutton brings you to the dialog transaction Manage Set of Rules for Value Date.

● ChangeChoosing 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 documentsChoosing this pushbutton opens the dialog transaction Manage Set of Rules for Value Date with dialog box Display Change Documents of the value date agreement.


Master Data

● ReleaseThis method in the Business Workplace can change the status and release status of the value date agreement as follows:Editing the value date agreement:


Status of the Value Date Agreement

Release Status Status of the Value Date Agreement

Release Status


● RejectChoosing 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:


Status of the Value Date Agreement

Release Status Status of the Value Date Agreement

Release Status


More Information









Related Information



Master Data


20.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 SLAA 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.

● Customer segment SLAAn 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 SLAAn SLA stored at customer group level.You use customer group SLAs to define special conditions for groups, such as corporate groups.

● Customer SLAAn 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 channelsA customer is only allowed to use certain channels and payment products.

● Payment amount limitFor certain payment products, a customer must not exceed certain amounts when sending payment orders to a financial institution.

ExampleIn 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 timeA 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.

ExampleA 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 lockCertain 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.

ExampleA 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.

In country risk management, a bank might decide that a particular country is too risky for credit transfers.

● CorrespondenceYou can define or block correspondence recipients. The different correspondence types are triggered by the specific processes in SAP Payment Engine.

● Foreign ExchangeYou 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 limitsYou 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 keysYou can specify whether a given instruction key (code word from input file) is allowed or not allowed.

● Country restrictionYou can specify that certain countries cannot receive transfers.


Master Data

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 AgreementsManage Service Level Agreements (transaction /PE1/SLA). For more information, see Managing Service Level Agreements [page 226].

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 pageDisplays 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 pageDisplays 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 pageDisplays a combination of channel, medium, and format. Payment orders that match the defined filter options are enriched with the SLA information.You can specify whether a given instruction key (code word from input file) is allowed or not allowed.

● Order Type Data tab pageDisplays 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 pageDisplays 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 pageDisplays options and rule sets for Foreign Exchange (FX) transactions.You can change Foreign Exchange (FX) rates. For more information, see Foreign Exchange (FX) [page 250].

● Charges tab pageDisplays 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 pageDisplays the correspondence options and rules, such as correspondence type, role, and recipient.

● Admin Data tab pageDisplays 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 231]Enrichment and Validation (FS-PE-EV) [page 276]Enrichment and Validation Check [page 278]

20.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:


To create and change an SLA:

● You have defined the release workflow in Customizing for Payment Engine under Payment Order SLARelease 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 .


Master Data

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

NoteThese 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 AgreementsManage 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.

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 384].


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.

20.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.

Use

Customizing


You make the settings for release object SLA in Customizing for Payment Engine under Payment Order SLARelease for SLA in the following Customizing activities:


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.


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.


Master Data

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 221].

● DisplayChoosing this pushbutton brings you to the dialog transaction Manage Service Level Agreements.

● ChangeChoosing 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 documentsChoosing this pushbutton opens the dialog transaction Manage Service Level Agreements with dialog box Display Change Documents of the service level agreement.

● ReleaseThis method in the Business Workplace can change the status and release status of the service level agreement as follows:Editing the service level agreement:


Status of the Service Level Agreement

Release Status Status of the Service Level Agreement

Release Status


● RejectChoosing 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:


Status of the Service Level Agreement

Release Status Status of the Service Level Agreement

Release Status


More Information



20.5.3 Status and Release Status of Master Data Objects






Master Data


Related Information


20.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 255].

● Payment Processing (in particular, enrichment and validation)For more information, see Payment Processing (FS-PE-POP) [page 274].

● Routing ControlFor more information, see Routing Control (FS-PE-RP) [page 172].


● Clearing ProcessingFor more information, see Clearing Processing (FS-PE-CP) [page 302].

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 340].

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 233] and Response Type [page 235].

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 251].

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 238].

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.


Master Data

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 66]

20.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 orderYou 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 orderProcessing of the payment order stops. The system rejects or reverses the payment order, depending on the processing status.

● 04 Automatic postprocessing of payment orderSimilar 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 authorizationProcessing 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.

NoteThe 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 276].

● 07 Reprocessing of outgoing payment orderAn offset clearing is posted, a failed transaction is copied to a new outgoing order and can be processed again.

● 08 Resubmission of outgoing payment orderYou can make manual changes to failed transactions. Afterwards, you can send them out. No clearing offset is made.

● 99 Further processingThe system ignores the error and resubmits the payment order for straight-through processing. For more information, see End-to-End Payment Processing [page 66].

Response Categories for Payment Items

Payment Engine provides the following response categories for payment items:

● 11 Postprocessing of payment itemYou 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 itemProcessing of the payment item stops. The system performs a corresponding posting to the ordering party. For more information, see Processing of Active Returns [page 251].

● 13 Redirection of payment itemThe 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 substitutionThis 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 postingThe 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 itemSimilar 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 typeYou can define a new transaction type for the payment item in Customizing.

● 16 Active return payment itemThe 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 251].

● 17 Request payment item authorizationProcessing 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.


Master Data

NoteThe 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 276].

● 18 Trigger return for internal payment itemThe 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 79].

● 19 Trigger return for external payment itemThe system initiates the return of payment items assigned to outgoing payment orders. For more information, see Active Request for Cancellation [page 76].

● 99 Further processingThe system ignores the error and resubmits the payment item for straight-through processing. For more information, see End-to-End Payment Processing [page 66].

Integration

You can define response types based on the response category in Customizing. For more information, see Response Type [page 235].

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 238].

20.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 241].

Integration

The following characteristics define a response type:

● Clearing areaA response type is valid in a defined clearing area.For more information, see Clearing Area [page 97].

● Response categoryA 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 233].

● PriorityWhen 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.

20.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.


Master Data

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.

ExampleThe 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● 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 apply5. 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 OrderDefine Response Types for Postprocessing , or Payment Engine Exception Control Define Response Types Response Types: Payment Item Define Response Types for Postprocessing

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 ProcessingException 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.

20.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 156].


Master Data

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 241].

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 244].

Structure

Exception Control Screen

The screen is divided into the following screen areas:

● Search areaYou 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 treeDisplays 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 categoryIdentifies 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 phaseSpecifies 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 objectDisplays 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 ChecksDisplays the possible error checks. These checks are available as a characteristic of the rule when you add the rule to a rule set.


NoteYou can enhance the predefined error checks in your customer name space.

○ Possible ResponsesDisplays the possible response categories. These response categories limit the response types available for selection when you add a rule to the rule set.

● RulesDisplays the rules in a rule set associated with the selected process, object category, and Exception Control phase.

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.


Master Data

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 383] and Release Object EH (Exception Control Rule Set) [page 246].

Change documents are available when rules or rule sets are changed. You can access change documents by choosing Extras Change Document .

20.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:

● ProcessFor 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 itemSuch 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.

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 operatorsCompare a predefined value of an attribute in a rule with the current value of a given payment item or payment order.

● Interval checkChecks whether the given attribute value lies within the interval that can be defined with the help of “from” and “to” values.

● Pattern matchingIs 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


Master Data

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 checkIs 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.

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 Check ID


Payment Order Type Group for Exception Control

Description Response Type

Further Attributes

1 85 02 ≠ EH_100 Postprocessing of payment order

None

2 85 ≠ 02 ≠ EH_100 Rejection of payment order with correspondence

None

3 90 Ignore, further processing of payment order or payment item

None

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 238]


20.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 ControlException Handling Release for Exception Handling .

To display an exception control rule:


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.


Master Data

NoteYou 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 238] under Structure.

3. In change mode, do one of the following:


○ 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.


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.


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:





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.


3. In change mode, choose the rule that you want to delete and choose .The rule is selected for deletion.



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.



20.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



Master Data

You make the settings for release object EH in Customizing for Payment Engine under Exception ControlException Handling Release for Exception Handling in the following Customizing activities:


Channel

Dialog

Individual processing: transaction Define Exception Control (/PE1/EH)

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.


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 248].

● DisplayChoosing this pushbutton brings you to the dialog transaction Define Exception Control.

● ChangeChoosing 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 documentsChoosing 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:


Status of the Exception Control Rule Set

Release Status Status of the Exception Control Rule Set

Release Status


● RejectChoosing this pushbutton rejects the change of the exception control rule set.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:


Status of the Exception Control Rule Set

Release Status Status of the Exception Control Rule Set

Release Status


More Information

Exception Control Rule Set [page 238]





Master Data




Related Information




20.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 287]

● Errors raised by the account management system● Currency translation options and rule sets in the service level agreement

NoteIf 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 ItemDetermine 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 processing4. Update of the bank FX positions by a separate order which will be released for processing upon posting to

the accounting system


Master Data

Related Information

Foreign Exchange (Overview) [page 90]Foreign Currency Trade Reporting [page 355]

20.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.

NoteYou 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 GroupsDefine 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 .

NoteIf 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 .


● 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 231].○ 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.

NoteIf 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)

NoteThe 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.

NoteIf 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.


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)

NoteThe 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 66]

20.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 254].


Prerequisites

● You have made the required setting in Customizing for Payment Engine (FS-PE), under Exception ControlDefine 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.

20.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 ControlDefine 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.


Master Data

21 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).


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:

● FormatThe original format of the payment order, such as SWIFT, SEPA, or XML.

● MediumThe physical data storage device that is used to transfer payment transaction files, such as a hard drive or optical device.

● ChannelThe 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 121].

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 231].

Payment Engine (FS-PE)File Handler (FS-PE-FH) PUBLIC 255

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 123].

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 257].

● 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 261].

● 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 263].

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


File Handler (FS-PE-FH)

21.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 274]. 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 172] and Clearing Processing (FS-PE-CP) [page 302].

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 .

NoteExternal 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


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 112].

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).

NoteYou can also use transactions /PE1/POLLER and /PE1/PO_EXPERT. For more information, see Import Data (Expert) [page 259].



● 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 264].

More Information


Output Manager [page 261]

File Handler Database [page 263]

For more information about the XML converter, see XML Converter [page 265] and SAP Note 1559115.

21.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.

NoteYou 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 257] under Prerequisites.


Features

Selection

● Converter IDIdentifies the converter to be used and is specified by a combination of format, medium, and channel.

● Format, Medium, and ChannelIf 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 338].

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).

NoteYou can also use transactions /PE1/POLLER and /PE1/PO_EXPERT to import data.



21.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 172] and Clearing Processing (FS-PE-CP) [page 302].

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

NoteFor 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 231].

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.

ExampleYou 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.

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


Input Manager [page 257]


For more information about bulking, see the report documentation.

For more information about the bulk assignment of request agents, see Request Agent [page 118] and Entering Master Data for Bulk Assignment of Request Agent [page 185].

21.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

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 257]. 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 261].

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 264].

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.

21.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.

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

○ DatabaseDisplays data stored in the File Handler database

○ ArchiveDisplays data that was stored in the File Handler database that the system has archived

NoteThe data in the File Handler database is archived after the residence time has expired. For more information, see Archiving (FS-PE-ARC) [page 384]

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


21.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)○ 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.

21.4.1 ISO 20022 Converter

Definition

SAP Payment Engine supports the following ISO 20022 payment standards:

PAIN.001 Customer Credit Transfer Initiation

PAIN.002 Customer Payment Status Report

PAIN.007 Customer Payment Reversal

PAIN.008 Customer Direct Debit Initiation

PAIN.013 Creditor Payment Activation Request

PAIN.014 Creditor Payment Activation Request Status Report

PACS.002 FI to FI Payment Status Report

PACS.003 FI to FI Customer Direct Debit

PACS.004 Payment Return

PACS.007 FI to FI Payment Reversal

PACS.008 FI to FI Customer Credit Transfer


CAMT.029 Resolution of Investigation

CAMT.054 Bank to Customer Debit Credit Notification

CAMT.055 Customer Payment Cancellation Request

CAMT.056 FI to FI Payment Cancellation Request

NoteThere are special formats for SEPA. These inclue EBA (European Banking Authority) and EPC (European Payments Council)

These lists of payment standards do not claim to be complete.

More Information



21.4.2 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 terminal for authorization of an amount

0120 Authorization Advice In case a point-of-sale terminal is damaged or the process times out and the switch stands in

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 Advice (Outgoing) Receipt confirmation of authorization 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 (Outgoing) Issuer response to request for funds

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 message 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 (Outgoing) Receipt confirmation of financial advice

0400 Acquirer Reversal Request Reversal of transaction



0420 Acquirer Reversal Advice Advices that a reversal has taken place

0421 Acquirer Reversal Advice Repeat Message If the reversal times out

0430 Issuer Reversal Response (Outgoing) Receipt confirmation of reversal advice

21.4.3 SWIFT 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

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 Expenses

n92 Request for Cancellation

n95 Queries

n96 Response

n98 Proprietary Message

n99 Free Format Message

NoteFor some of the SWIFT converters there is a UI for non-financial messages. For more information, see Investigate Non-Financial Messages [page 357].

21.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



21.6 Eurogiro

The Eurogiro standard was developed by Eurogiro, an association of postbanks, banks and money transfer organisations.

The following Eurogiro formats are processed.

Format Channel

MT103 Incoming and Outgoing

MT910 Incoming

MT198-93 Incoming and Outgoing

21.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 HandlerStatus 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.

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) 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 NotificationBusiness Add-Ins (BAdIs) BAdI: Adjustment of Payment Transaction Status for pain.002 .


22 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.


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 276].

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 231].

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 172] and Clearing Processing (FS-PE-CP) [page 302].

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 processingOn the SAP Easy Access screen, choose Payment Engine Periodic Processing Processes Execute Processes (transaction /PE1/POLLER).


Payment Processing (FS-PE-POP)

● Display an overview of payment orders and payment items and manage payment orders and payment itemsOn 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 338].

● Manage service level agreementsAs 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 AgreementsManage Service Level Agreements (transaction /PE1/SLA).For more information, see Service Level Agreement [page 276] and Managing Service Level Agreements [page 226].

● Define and perform enrichment and validation checksYou 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 ordersIf 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 paymentsYou can create recalls only for payment orders and payment items that have not been finally processed. For more information, see Recall Management [page 112]. Payment Engine also support the cancellation of SEPA Direct Debits (SDD). For more information, see Request for Cancellation [page 74].

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_GETDETAILRetrieves 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_GETDETAILRetrieves 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.

NoteYou 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)Payment Processing (FS-PE-POP) PUBLIC 275

22.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 231]. 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 accuracyFor example, account format checks check whether an account is valid for a respective country.

● Referential accuracyFor example, the IBAN check checks whether a payment order has an IBAN and whether the IBAN is correct.

● Material errorsFor 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.

● ConsistencyFor 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 295] and Enrichment and Validation Checking [page 280].

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 223] and Managing Service Level Agreements [page 226].



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.

NoteThe 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 274]



22.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.


The system determines one of the following processing modes:

● E- Execution modeDetermined 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 modeDetermined 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 modeDetermined 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 276]

22.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 280].

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 .

CautionDo 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.



Structure

All enrichment and validation checks must have the same structure. You must configure new checks in accordance with the following structure:

● Check IDIdentifies a customized enrichment and validation check.

● Check typeSpecifies what the system is to check (payment order, payment item, or cross-item checking).

● Error IDDefines the error handling category for Exception Control.

● Routine classSpecifies the routine class that contains the check method to be performed.

● Routine methodSpecifies the method that performs the enrichment and validation check (the check itself).

● Check statusEnables or disables an enrichment and validation check for Exception Control.

● Accumulation classSpecifies the routine class that contains the check method to be performed for cross-item checking.

● Accumulation methodSpecifies 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 231].

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 .


More Information

Enrichment and Validation Check Set [page 295]

22.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 .

NoteYou 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 277].

The system performs validation checks at different levels. For more information, see:

● Payment Order Checks [page 281]● Ordering Party Item Checks [page 284]



● Recipient Item Checks [page 287]● Cross Item Checks [page 292]

NoteThe 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 276]

Enrichment and Validation Check [page 278]


22.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 280] 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 .


Features

The following table describes the payment order checks supported by Payment Engine.

Payment Order Checks

Check Method Description

Enrichment Ordering Customer SLA

(CHECK_E_SLA)

Enriches a payment order with the SLA based on the account information of the ordering party item.

Segment Enrichment

(CHECK_E_SEGMENT)

Enriches the ordering party item with the customer ID and the segment ID and the payment order with the segment ID.

Check Authority Flag

(CHECK_V_CUST_AUTH_FLG)

Checks whether:

● 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 under

Payment Order Payment Order Enrichment and

Validation Check Specific Configuration Maintain Order

Limits for Payment Order Authorization .

Check Submission Agreement Exists

(CHECK_V_ORD_TYPE_FORMAT)

Checks whether the ordering party is authorized to submit payment orders with a specific combination of format, channel, and payment order type group as defined in the SLA.

Validate Mass Credit/Direct Debit/Bank

(CHECK_V_TYPE)

Checks whether the defined payment order type is valid for the clearing area.

Format/Medium/Channel Validation

(CHECK_V_FORMAT_MEDIUM_CHANNEL)

Checks that the combination of format, medium, and channel is valid against the SLA. Furthermore, the format, medium, and channel are checked for validity independently according to the setting defined in Customizing for Payment

Engine under File Handler Basic Settings .


(CHECK_V_PRIORITY)

Checks whether the priority is valid for the clearing area.

Determine Client/Customer-Specific Prioritization

(CHECK_E_PRIORITY)

Gives another prioritization if a higher priority is defined in the SLA than in the payment order.




Bank Key/ BIC Validation

(CHECK_V_BLZ_BIC)

Checks whether the bank code and the BIC of the external sender are valid (in PE1/T_BLZ and /PE1/T_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

(CHECK_V_CUT_OFF_TIME)

Checks whether a payment order is delivered within the timeframe defined in the SLA. This check is only performed if the planned processing date is equal to the functional submission date and the current reconciliation date.

Planned Processing Time Enrichment

(CHECK_E_PROC_TIME)

Determines and enriches the planned processing time for a payment order.

Check FH Error Flag

(CHECK_V_FH_FORMAT_ERROR)

Checks whether an error was detected in the payment order in File Handling.

Recall Check

(CHECK_V_PO_RECALL)

Checks whether a recall exists for a payment order.

Bank File Clearing Data

(CHECK_E_BNKCLEAR)

Determines the clearing account of an ordering party item of incoming payment orders by using the data defined 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

CHECK_E_BANK_BP_ACCOUNT

Determines the clearing account of an ordering party item of incoming payment orders by using the account information 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 enriches the indicator at the order object.

Check Requirement of Cover Funds

CHECK_E_COVER_FUNDS_REQUIRED

Checks whether cover funds are required.

Check for Duplicate Orders

CHECK_ORDER

Checks for duplicate orders. The check is contained in class PE1/CL_PO_EV_DUPLICATE_PO2.



Mandatory Fields Check

CHECK_V_MUST_FIELDS_PO

Checks whether mandatory fields are filled in.

More Information



Cross Item Checks [page 292]

22.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 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 ordering party item checks supported by Payment Engine.



Payment Item Checks — Ordering Party Items


Check Transaction Type Locking Check

(CHECK_V_TRANSXN_TYPE)

Checks whether the transaction type (group) is locked in the determined SLA.

Check Transaction Type

(CHECK_V_TRANS_TYPE)

Checks whether the transaction type is valid in accordance with the setting defined in Customizing for Payment Engine

under Payment Item Transaction Types and Transaction

Type Groups Define Transaction Types .

Maximum Amount per Transaction Type

(CHECK_V_MAX_AMOUNT_X_TYPE)

Checks the transaction type of the payment item against a limit defined in Customizing for Payment Engine under

Payment Item Transaction Types and Transaction Type

Groups Define Transaction Types .

Check Payment Item Priority

(CHECK_V_PI_PRIORITY)

Assigns the highest priority of either the payment item or the value defined in the SLA.


(CHECK_E_PRIORITY)

Assigns the highest priority from either the payment item or the value defined in the SLA.

Customer-Specific Payment Item Amount Limit Check

(CHECK_V_AMOUNT_LIMIT)

Validates the transaction amount of the ordering party item against a limit customized in the SLA for each transaction type.

Calculation of Posting Date

(CHECK_E_POSTING_DATE)

Determines the posting date for an ordering party item based on the due date.

Feedback Date Calculation

(CHECK_E_LATEST_FBACK_DATE)

Determines the latest feedback date required from the account management system to start processing on time and meet the due date: latest feedback date = due date – minimum offset (the settlement date or the due date for submission of a payment transaction).

You define the minimum offset in Customizing for Payment

Engine under Exception Control SEPA .

Transaction Currency/Amount

(CHECK_V_TR_AMOUNT)

Validates fields TR_AMOUNT and TR_CURR.

Account Currency/Amount

(CHECK_V_A_AMOUNT)

Validates fields A_AMOUNT and A_CURR.



Check Account Substitution

(CHECK_E_ACC_SUBSTITUTION)

Substitutes the account information based on a defined account substitution rule (rules can be created using a BAPI in the standard system or by using transaction /PE1/MN_ACCSUBS).

For more information, see Account Substitution [page 153].

Account Number Checksum

(CHECK_E_ACC_NR_CHECKSUM)

Validates the checksum of the account number against defined checksum methods that you can define in Customizing

for Payment Engine under Payment Order Payment

Order Enrichment and Validation Check Specific

Configuration Maintain Checksum Methods .

Account Details

(CHECK_V_ACCOUNT)

Validates account information.

Bank Key/BIC Validation

(CHECK_V_BLZ_BIC)

Checks for a valid bank code and BIC in /PE1/T_BLZ and /PE1/T_BIC.

The method checks the following attributes:

● Bank key● BIC code (SWIFT address)● Bank key reference account● BIC reference account

IBAN Validation

(CHECK_V_IBAN)

Checks the structure and validity of the IBAN.

Extracts the bank country, bank key, and account number.

BBAN/IBAN Validation

(CHECK_V_BBAN_IBAN)

Validates the following fields:

COUNTRY, BANKKEY, ACCT_NO, IBAN and REF_COUNTRY, REF_BANKKEY, REF_ACCT_NO, REF_IBAN

IBAN/BIC Validation

(CHECK_V_IBAN_BIC)


IBAN, BIC and REF_IBAN, REF_BIC

Derive IBAN from BBAN

(CHECK_E_BBAN_IBAN)

Derives the IBAN from the BBAN.

It is also possible to enable third-party determination of account data based on the IBAN by using BAdI /PE1/BADI_BIC_UTILITIES.

Derive BIC from IBAN

(CHECK_E_IBAN_BIC)

Derives the BIC from the IBAN. It is also possible to enable third-party determination of the BIC based on the IBAN by using BAdI /PE1/BADI_BIC_UTILITIES.




ISO Code Validation

(CHECK_V_ISO)

Validates the ISO code in accordance with ISO-3166.

Check of Blank Checks

(CHECK_V_BLANK_CHEQUE)

Validates the number of blank checks against manually maintained check numbers in Payment Engine.

Embargo Check: PI is Embargo Relevant

(CHECK_V_EMBARGO)

For information, see Embargo Check [page 298].

Check FH Error PI


Checks whether an error was detected in the payment item in the File Handler.

Crisis Check

CHECK_V_CRISIS

Checks whether the payment item is affected by a crisis situation.


CHECK_V_MUST_FIELDS_PI


More Information

Payment Order Checks [page 281]



22.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.

Prerequisites






Features

The following table describes the recipient item checks supported by Payment Engine.

Payment Item Checks — Recipient Items


Transaction Type Validity Check

(CHECK_V_TRANS_TYPE)

Validates the transaction type against the settings defined in

Customizing for Payment Engine under Payment Item

Transaction Types and Transaction Type Groups Define

Transaction Types .

Check Transaction Type Locking Check

(CHECK_V_TTYPE_LOCK)

Payment

Checks whether the transaction type or transaction type group of the payment item is locked for the item in the SLA.

Maximum Amount per Transaction Type

(CHECK_V_MAX_AMOUNT_X_TYPE)

Checks the transaction of the item against a limit defined in

Customizing for Payment Engine under Payment Item

Transaction Types and Transaction Type Groups Define

Transaction Types .

Segment Enrichment

(CHECK_E_SEGMENT)

Enriches the payment item with the segment the customer belongs to.


(CHECK_E_PRIORITY)

Assigns the highest priority from either the payment item or the value defined in the SLA.







Customer-Specific Payment Item Amount Limit Check

(CHECK_V_AMOUNT_LIMIT)

Checks the amount against an amount limit for the payment order type group or payment order type defined in the SLA.

Country Restriction

(CHECK_V_CNTRY_RESTRICTION)

Checks whether the SLAs assigned to the payment order contain a restriction for the bank country and the transaction category of the recipient item.

Calculation of Posting Date

(CHECK_E_POSTING_DATE)

Determines the posting date for the recipient item based on the due date.

SEPA Timestamp Too Late

(CHECK_V_DUE_DATE_LATE)

Checks whether the latest possible submission date of a SEPA transaction for a given due date is violated according to the settings defined in Customizing for Payment Engine

under SEPA Maintain SEPA Timeframe Validation .

SEPA Timestamp Too Early

(CHECK_V_DUE_DATE_EARLY)

Checks whether the earliest possible submission date of a SEPA transaction for a given due date is violated according to the settings defined in Customizing for Payment Engine

under SEPA Maintain SEPA Timeframe Validation .

Timeframe Validation of SEPA R-Transactions

(CHECK_V_AR_TIMEFRAME)

Checks whether an R-transaction is submitted within a timeframe defined in Customizing for Payment Engine under

SEPA Maintain SEPA Timeframe Validation .

Check Recall Payment Item

(CHECK_V_PI_RECALL)

Checks whether a recall exists for the recipient item.

Send-Back Validation

(CHECK_V_AR_ITEM)

Checks whether the original item was already subject of an R-transaction.

SEPA Check for Bank Country

(CHECK_V_SEPA_COUNTRY)

Checks the bank country field of incoming payment items against the countries defined in Customizing Payment

Engine under SEPA Maintain SEPA Country Checkwhere you define countries that are members of the Single European Payments Area (SEPA).

Transaction Currency/Amount

(CHECK_V_TR_AMOUNT)

Validates fields TR_AMOUNT and TR_CURR.

Account Currency/Amount

(CHECK_V_A_AMOUNT)

Validates fields A_AMOUNT and A_CURR.



Account Number Checksum Validation

(CHECK_E_ACC_NR_CHECKSUM)

Validates the checksum of the account number against defined checksum methods.

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

(CHECK_E_ACC_SUBSTITUTION)

Substitutes the account information based on a defined account substitution rule (rules can be created using a BAPI in the standard system or by using transaction /PE1/MN_ACCSUBS).

For more information, see Account Substitution [page 153].

Account Details

(CHECK_V_ACCOUNT)

Validates the account information.

BBAN/IBAN Validation

(CHECK_V_BBAN_IBAN)


COUNTRY, BANKKEY, ACCT_NO, IBAN and REF_COUNTRY, REF_BANKKEY, REF_ACCT_NO, REF_IBAN

IBAN Validation

(CHECK_V_IBAN)

Validates the structure and checksum of the IBAN.

Extracts the bank country, bank key, and account number.

Bank Key/BIC Validation

(CHECK_V_BLZ_BIC)

Checks for a valid bank key and BIC in /PE1/T_BLZ and /PE1/T_BIC.

The method checks the following attributes:

● Bank key● BIC code (SWIFT address)● Bank key reference account● BIC reference account

IBAN/BIC Validation

(CHECK_V_IBAN_BIC)


IBAN, BIC and REF_IBAN, REF_BIC.

Derive BIC from IBAN

(CHECK_E_IBAN_BIC)

Derives the BIC from the IBAN.

It is also possible to enable third-party determination of the BIC based on the IBAN by using BAdI /PE1/BADI_BIC_UTILITIES.




Derive IBAN from BBAN

(CHECK_E_BBAN_IBAN)

Derives the IBAN from the BBAN.

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

(CHECK_E_CLEARING_SYSTEM)

Enriches the clearing system based on the routing directory.

Foreign Country Enrichment

(CHECK_E_FOREIGN_MARK)

Enriches the foreign country mark from the order.

ISO Code Validation

(CHECK_V_ISO)

Validates the ISO code.

Embargo Check

(CHECK_V_EMBARGO)

For information, see Embargo Check [page 298].

Check FH Error PI


Checks whether an error was detected in the payment item in the File Handler.

Check for FX scenario

(CHECK_V_FX_SCENARIO)

Checks for FX scenario

Transaction Chain Validation

(Cross border)

Checks the ordering BIC, the beneficiary BIC, and the transaction currency to determine the payment transaction chain.

Transaction Charge Validation

(CHECK_V_TRANS_CHARGES)

Validates the charges provided by a sender bank in a BEN scenario based on the:

● Charge condition group● Bank identifier code (BIC)● Charge category● Transaction currency● Transaction amount● Validity date

Enrich the account currency based on internal data

(CHECK_E_ACCOUNT_CURRENCY)

Enriches the account currency based on internal data

Payment Item Check Operation

(CHECK_V_CUSTOM_RATE_SUBMISSION)

Operates the Payment Item Check



Crisis Check

CHECK_V_CRISIS

Checks whether the payment item is affected by a crisis situation.




More Information




22.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.

NoteThe 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 Customizing settings for enrichment and validation of payment orders. For more information, see Payment Order Checks [page 281] under Prerequisites.

● You have defined the Customizing settings for enrichment and validation of payment items. For more information, see Ordering Party Item Checks [page 284] or Recipient Item Checks [page 287] under Prerequisites.



Features

The following table describes the cross item checks supported by Payment Engine.

Cross Item Checks


Ordering Party Item Split

(CHECK_E_ORP_SPLIT)

Splits the ordering party item based on the attributes of the recipient item, such as transaction type group, reference account connection, internal/external flag, or SAP client flag.

You can customize the transaction types for splitting ordering 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

(CHECK_V_ITEMS_AMOUNT_LIMIT)

Checks whether the amount of the payment items is exceeded for a special payment order type/payment order type group in the determined SLA.

Duplicate Check Payment Order

(CHECK_ORDER)

Checks for duplicate processing of a payment order by calculating a checksum.

In the SLA, you can define whether the duplicate check is executed, not executed, or ignored.

Credit/Debit Check

(CHECK_V_DEBIT_CREDIT)

Compares the amount of the ordering party item and recipient items and sets an error if there is an imbalance.

Error Rate Check Recipient Items

(CHECK_V_NUM_INCORRECT_RCPITEMS)

Calculates the error rate of fatal and all errors of recipient items and generates an error if the error rate defined for a 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

(CHECK_E_TRANS_CHARGES)

Enriches the ordering party item with the payment transaction charges determined for the recipient item.

More Information





22.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





Features

The following table describes the recipient item checks supported by Payment Engine.

Payment Item Checks — Recipient Items


Check Recall Payment Item

(CHECK_V_PI_RECALL)

Checks whether a recall exists for the recipient item.







Mandatory

Fields Check



More Information



Recipient Party Item Checks [page 287]


22.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 278].

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 ValidationMaintain Enrichment & Validation Check Sets .


Structure

An enrichment and validation check set has the following structure:

● Clearing areaSpecifies a legally independent organizational unit in Payment Engine.

● Check set IDIdentifies a rule that comprises customized checks for enrichment and validation.

● Rule typeSpecifies 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.


● Payment order type group for enrichment and validationSpecifies the payment order type group for enrichment and validation.



● Enrichment and validation set typeSpecifies whether the enrichment and validation set type is executed for payment orders or for cross-item checking.

● Execution timeSpecifies when checks are carried out:○ E: at execution.○ S: at submission.○ X: at both submission and execution.

● ChannelDescribes the method that can be used to transfer payment orders between financial institutions.

● FormatDefines the fields and the record structure of the payment order record set.

● Payment order enrichment and validation check set IDIdentifies 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 ValidationMaintain 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.


● Transaction type group for enrichment and validationSpecifies the transaction type group for enrichment and validation.

● Enrichment and validation set typeSpecifies whether the enrichment and validation set type is executed for order party items or recipient items.

● Execution timeSpecifies when checks are carried out:○ E: at execution.○ S: at submission.○ X: at both submission and execution.

● Internal/External indicatorSpecifies whether the entry refers to external or internal posting items on the recipient side.

● ChannelDescribes the method that can be used to transfer payment orders between financial institutions.

● FormatDefines the fields and the record structure of the payment order record set.

● SAP Client Internal/External FlagIndicates whether the SAP client is internal or external.

● Payment item enrichment and validation check set IDIdentifies an enrichment and validation check set rule of payment items checks.


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 277]

22.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 138].

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 276].

● 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 231].

NoteIf 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



embargo confirmation instead of carrying out a full check. Please take this into account when you configure the enrichment and validation (E&V) checks.

22.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 231].

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


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 itemsYou 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 errorsIf 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 Checking [page 280]

22.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 ItemPayment 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 ProcessingRecipient Item Enrichment & Validation .

If you create prenotes for clearing items, any incorrect items are removed from the outgoing payment order.



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


22.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



23 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 clearingThe 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 instituteNeither financial institution has a clearing account with the other.

● Clearing with a separate cover provisionNeither 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 274] and Routing Control (FS-PE-RP) [page 172].

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 231].

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 329].

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


Clearing Processing (FS-PE-CP)

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 255].

NoteFor more information, see Direct Clearing [page 322].

● QueuingThe 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 304].

● CollectionPayment 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.

NoteIf 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 itemsThe 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 311].

NoteQueues 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 queuesFor more information, see Assign Payment Items to Collector/Queue [page 323].

● Close collectors and queuesFor more information, see Close Collector/Queue [page 325].

● Initiate final processing of collectors and payment items parked in queuesFor more information, see Final Processing (Collector/Queue) [page 327].

Payment Engine (FS-PE)Clearing Processing (FS-PE-CP) PUBLIC 303

23.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.

NoteYou define whether payment items are collected in queues in clearing agreements. For more information, see Setting Up Queues and Collectors [page 307].

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 323].

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 queueThe 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 queueThe 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 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 areaYou can enter a text to search for clearing agreements currently loaded in the navigation tree.

● Navigation treeDisplays collection types, combinations of routes and clearing agreements, collection categories, and existing queues for the selected clearing area in a hierarchical structure.

● Business objectDepending 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 186] under Collector Processing (Collector Only).

○ Collection categoryDisplays the characteristics that define the queue category.

○ QueueDisplays 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 ClearingMaintain Number Ranges for Collectors .

● SequenceSpecifies a processing sequence within a queue category.

● DirectionDisplays whether the queue is intended for processing internal or external payments.

Basic Data


● Status informationDisplays the status of the queue. Only the statuses Open and Closed are relevant for queues.

● Closing informationDisplays 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 attributesDisplays 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 accountDisplays 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).



23.1.1 Setting Up Queues and Collectors

Prerequisites


● 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 186] 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.


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 186] under Collector Processing (Collector Only).

5. Define the following settings:


○ Separation criteria for assignmentDefine 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

NoteYou 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

NoteYou can separate payment items by original message ID in the context of requests for payment cancellation. For more information, see Request for Cancellation [page 74].

○ 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

NoteIn 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 processingYou 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.


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 EngineClearing Manage Collectors and Queues (transaction /PE1/CP_COLL).



Next Steps

Queue [page 304]

Collector [page 311]

23.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 EngineMaster Data Routing Control Manage Routes and Clearing Agreements (transaction /PE1/RN).

● The queues that you want to process have the status Open.


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.


● Expand the navigation tree to display the available combinations of route and clearing agreement, queue categories, and sequences.

NoteThe 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 ProcessingProcesses 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.

NoteWhen 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 304] 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.



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 307].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.

NoteYou 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 323]● Close Collector/Queue [page 325]● Final Processing (Collector/Queue) [page 327]

NoteYou 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 .

23.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.


NoteYou define whether payment items are collected in collectors in clearing agreements. For more information, see Setting Up Queues and Collectors [page 315].

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 334], Posting Simulation [page 331], and Completing Mandates [page 346].

Payment Engine uses the following types of collectors:

● Customer collector for internal payment itemsUsed 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.

ExamplePayments 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 317].● 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 319].

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 325].

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 323].

Structure

Collector Screen

The collector 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.● 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.

NoteIf collection by due date and direct debit type is enabled, the due date and direct debit type are displayed for the collector sequences.

● Business objectDepending 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 186] under Collector Processing (Collector Only).

○ Collection categoryDisplays the characteristics that define the collector category.

○ CollectorDisplays 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 ClearingMaintain Number Ranges for Collectors .

● SequenceSpecifies a processing sequence within a collector.

● DirectionDisplays whether the collector is intended for processing internal or external payments.

Basic Data

● Status informationDisplays 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○ 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 informationDisplays 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 attributesDisplays 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 accountDisplays 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.



23.2.1 Setting Up Queues and Collectors

Prerequisites


● 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 186] 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.


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 186] under Collector Processing (Collector Only).

5. Define the following settings:


○ Separation criteria for assignmentDefine 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

NoteYou 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

NoteYou can separate payment items by original message ID in the context of requests for payment cancellation. For more information, see Request for Cancellation [page 74].

○ 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

NoteIn 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 processingYou 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.


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 EngineClearing Manage Collectors and Queues (transaction /PE1/CP_COLL).



Next Steps

Queue [page 304]

Collector [page 311]

23.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 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



Displaying Customer Collectors


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.


● Expand the navigation tree to display the available combinations of route and clearing agreement, collector categories, and 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 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.

NoteWhen 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.


For more information about the collector screen, see Collector [page 311] 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 186].

3. Switch to change mode and change the settings.For more information, see Setting Up Queues and Collectors [page 315].




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.


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.

NoteYou 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:



23.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


● 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 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



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.


● Expand the navigation tree to display the available combinations of route and clearing agreement, collector categories, and sequences.


NoteIf 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.



● 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.

NoteWhen 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.


For more information about the collector screen, see Collector [page 311] 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 186].

3. Switch to change mode and change the settings.For more information, see Setting Up Queues and Collectors [page 315].


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.


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.

NoteYou 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 Clearing Collector

You can process all payment items in a clearing collector manually. For more information, see:



23.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 186].

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○ 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 forwarded3. 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 261].

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.

23.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.

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 186].

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 307].

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 115].

● You can remove all payment items that are assigned to a queue or an open clearing collector from the given queue or clearing collector.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.

NoteYou 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 EngineClearing 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


Close Collector/Queue [page 325]

Final Processing (Collectors/Queues) [page 327]

23.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 186].

Prerequisites

You have defined the closing criteria: On the SAP Easy Access screen, choose Payment Engine Master DataRouting 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 criteriaYou 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 criteriaYou 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.

NoteWhen 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 EngineClearing 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 ProcessingProcesses Execute Processes (transaction /PE1/POLLER).

More Information


Assign Payment Items to Collector/Queue [page 323]

Final Processing (Collectors/Queues) [page 327]

23.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 231].

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 323].

● The collector or queue is closed. For more information, see Close Collector/Queue [page 325].● The conditions for processing are defined in the clearing agreement. For more information, see Setting Up

Queues and Collectors [page 307].● The clearing agreement is not locked before processing of the corresponding payment items starts. For

more information, see Clearing Agreement [page 186].● Payment Engine is connected to an account management system. For more information, see Connection to

an Account Management System [page 134].● 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


Assign Payment Items to Collector/Queue [page 323]

Close Collector/Queue [page 325]

23.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.


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 134].


NoteThis 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 302].

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 231].

Features

Processing

The main processing features of Account Management Proxy (the AM Proxy) are:

● Single processingThe AM Proxy handles payment data on a payment-item by payment-item basis.

● Synchronous and asynchronous processingThe 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 scenariosThe 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

During the clearing process, the system can call the AM Proxy to perform actions for payment items. For more information, see:

● Posting simulation [page 331].● Posting [page 333].● Reservation [page 334].



● Deletion of Reservation [page 335].

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 ItemsHandles 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 ItemsUpdates the status of items reported to be in process by a connected AMS.

● AM System Availability MonitoringProvides information about the availability status of a connected AMS.

● Poller Job Schedule Check ReportDisplays the number of payment items pending for the selected criteria.

● Buffer Monitoring ReportProvides an overview of payment items.

● PE/AM Transaction Type Consistency ReportCompares the entries in a connected AMS with the entries in Payment Engine.

● Reconciliation of PE and AMProvides information about discrepancies between Payment Engine and a connected AMS.

● Evaluation of Outgoing Items Sent to AM SystemProvides 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 365].

23.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● Account lock● Account number (name comparison)● Check lock

For more information, see Direct Clearing [page 322].


NoteThe 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 334] and Posting [page 333].

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 134].

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



Periodic Processing [page 365]

Logs [page 380]



23.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 331].

Postings can usually be executed within a direct clearing scenario or within a collection scenario.

For more information, see Direct Clearing [page 322] and Collector [page 311].

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.


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





Logs [page 380]

23.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 322], Collector [page 311], Assign Payment Items to Collector/Queue [page 323], and Final Processing (Collectors/Queues) [page 327].

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.


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






Logs [page 380]

23.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 334].

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.


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




Logs [page 380]


23.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 [page 267]. 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 92]



24 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 337]Exception Handling [page 352]Foreign Currency Trade Reporting [page 355]Manage Payment Blocks [page 356]Investigate Non-Financial Messages [page 357]Management Cockpit [page 358]Release [page 358]

24.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)User Interface PUBLIC 337

Related Information

Edit Payment Orders (Expert) [page 338]Create Payment (SAP Fiori) [page 347]Create Payment Order (SAPUI5) [page 349]Manage Payments (SAP Fiori) [page 350]Manage Waiting Payments (SAP Fiori) [page 350]Display Payment Order (SAPUI5) [page 351]

24.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

NoteThis function is available only for new payment orders or payment orders that require further processing.

● Reject payment orders


User Interface

NoteThis 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 251].

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 340]○ Creating Payment Orders and Payment Items [page 342]○ Changing Payment Orders and Payment Items [page 345]○ Completing Mandates [page 346]○ Deleting Payment Orders and Payment Items [page 344]

● 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 ExtrasChange 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 .


24.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


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 dataDisplays 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 dataDisplays 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.

● ExceptionDisplays 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 231].This tab page is typically displayed for payment orders that require postprocessing.


User Interface

● Date detailsDisplays the most commonly used and important date fields, such as the posting date, due date, and value date.

● File HandlerDisplays 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 263].

● ReferencesDisplays 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 dataDisplays 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 dataDisplays information such as the status, amount, transaction type, and direct debit type.

● Account dataDisplays information about the account, for example, the bank country, bank key, and BIC.

● Date detailsDisplays 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.

● ReferencesDisplays 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


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 remittanceYou 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 dataDisplays the user and date and time information related to the creation, update or release of a payment item.

● ExceptionDisplays 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).

NoteThe 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).

NoteYou 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 MonitoringDisplay Status Transitions .

More Information


24.1.1.2 Creating Payment Orders and Payment Items

Use

You can create payment orders and payment items manually.


User Interface

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.


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.

NoteYou can also import payment orders by using File Handler.

For more information, see Input Manager [page 257] and Import File (Expert) [page 259].

More Information

Payment Order [page 101]


Payment Item [page 106]

24.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 340].

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 .


User Interface

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.

24.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.


3. Choose your filter options.

For more information about the available filter options, see Payment Order and Payment Item Overview [page 340].

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.

24.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.


User Interface

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 338].

For more information about collectors, see Collector [page 311]

24.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


● 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

Determining Format/Medium/Channel by Reconciliation Units [page 348]

24.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 FioriConfiguring Launchpad Content Adding Apps to SAP Fiori Launchpad Configure Target Mappings and Tiles .


User Interface

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

24.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.

NoteThis 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 347].

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


automatically processed. The object ID and possible validation results are returned and become available at the bottom of the screen.

24.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.


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


24.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.

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.


User Interface

Prerequisites


24.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).

NoteThis 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 350].

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

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


24.2 Exception Handling

For exception handling, the following UIs are available:

● Repair Payments (SAP Fiori app)● Exception Handling (SAPUI5 app)

NoteWe recommend that you use the Repair Payments SAP Fiori app.

Related Information

Repair Payments (SAP Fiori) [page 352]Exception Handling (SAPUI5) [page 354]

24.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 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.

You can also reassign erroneous payment orders or items to another work basket.

Prerequisites


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 .


User Interface

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 UpdateUse 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.

NoteYou 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 SettingsGlobal 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

Recall [page 110]Edit Payment Orders (Expert) [page 338]

24.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.

NoteThis 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.

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 352]Exception Control (FS-PE-EH) [page 231]

24.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.



User Interface

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 made the relevant Customizing settings for correction rules as described in "Correction Rules".

Related Information

Correction Rules [page 236]

24.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 CurrenciesYou 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.

NoteThe 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

Foreign Exchange (Overview) [page 90]

24.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.


Prerequisites

You have configured the Fiori app as described in the Administrator's Guide for SAP Payment Engine under Post-Installation Tasks.


User Interface

24.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

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 269].


24.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 405].

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.

24.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.

The following detail views are available for the app:

● Order view● Order item view

NoteOther 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.


User Interface

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.

NoteTo 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.

24.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 360]


24.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/CL_FIORI_INBOX_DYN_ATTRS.GET_DYN_ATTR_VALUE_BY_OBJ(OBJECT=&_WI_OBJECT_ID& FIELD_NAME='VALUE_DATE')%

D

/SWL/ALL/DYNCO11 Country %/PE1/CL_FIORI_INBOX_DYN_ATTRS.GET_DYN_ATTR_VALUE_BY_OBJ(OBJECT=&_WI_OBJECT_ID& FIELD_NAME='COUNTRY')%

C

/SWL/ALL/DYNCO12 Create Date %/PE1/CL_FIORI_INBOX_DYN_ATTRS.GET_DYN_ATTR_VALUE_BY_OBJ(OBJECT=&_WI_OBJECT_ID& FIELD_NAME='CRDAT')%

D

/SWL/ALL/DYNCO13 Execution Date %/PE1/CL_FIORI_INBOX_DYN_ATTRS.GET_DYN_ATTR_VALUE_BY_OBJ(OBJECT=&_WI_OBJECT_ID& FIELD_NAME='PL_PROC_DATE')%

D

/SWL/ALL/DYNCO14 Sender BIC %/PE1/CL_FIORI_INBOX_DYN_ATTRS.GET_DYN_ATTR_VALUE_BY_OBJ(OBJECT=&_WI_OBJECT_ID& FIELD_NAME='SND_EXT_BIC')%

C


User Interface


/SWL/ALL/DYNCO15 Priority %/PE1/CL_FIORI_INBOX_DYN_ATTRS.GET_DYN_ATTR_VALUE_BY_OBJ(OBJECT=&_WI_OBJECT_ID& FIELD_NAME='PRIORITY')%

C

T/SWL/ALL/DYNCO16 Risk Score %/PE1/CL_FIORI_INBOX_DYN_ATTRS.GET_DYN_ATTR_VALUE_BY_OBJ(OBJECT=&_WI_OBJECT_ID& FIELD_NAME='RISK_SCORE')%

I

/SWL/ALL/DYNCO17 Work Basket %/PE1/CL_FIORI_INBOX_DYN_ATTRS.GET_DYN_ATTR_VALUE_BY_OBJ(OBJECT=&_WI_OBJECT_ID& FIELD_NAME='WORK_BASKET_ID')%

C

/SWL/ALL/DYNCO18 ORP Account Number %/PE1/CL_FIORI_INBOX_DYN_ATTRS.GET_DYN_ATTR_VALUE_BY_OBJ(OBJECT=&_WI_OBJECT_ID& FIELD_NAME='WORK_BASKET_ID')%

C

T/SWL/ALL/DYNCO19 Clearing Area %/PE1/CL_FIORI_INBOX_DYN_ATTRS.GET_DYN_ATTR_VALUE_BY_OBJ(OBJECT=&_WI_OBJECT_ID& FIELD_NAME='CLEARING_AREA')%

C

/SWL/ALL/DYNCO20 Change User %/PE1/CL_FIORI_INBOX_DYN_ATTRS.GET_DYN_ATTR_VALUE_BY_OBJ(OBJECT=&_WI_OBJECT_ID& FIELD_NAME='CHUSR')%

C



/SWL/ALL/DYNCO21 Transaction Amount %/PE1/CL_FIORI_INBOX_DYN_ATTRS.GET_DYN_ATTR_VALUE_BY_OBJ(OBJECT=&_WI_OBJECT_ID& FIELD_NAME='TR_AMOUNT')%

F

/SWL/ALL/DYNCO22 Sum of Amounts %/PE1/CL_FIORI_INBOX_DYN_ATTRS.GET_DYN_ATTR_VALUE_BY_OBJ(OBJECT=&_WI_OBJECT_ID& FIELD_NAME='SUM_ITEMS')%

F

/SWL/ALL/DYNCO23 Sum Currency %/PE1/CL_FIORI_INBOX_DYN_ATTRS.GET_DYN_ATTR_VALUE_BY_OBJ(OBJECT=&_WI_OBJECT_ID& FIELD_NAME='SUM_CURR')%

F

/SWL/ALL/DYNCO24 Release Activity %/PE1/CL_FIORI_INBOX_DYN_ATTRS.GET_DYN_ATTR_VALUE_BY_OBJ(OBJECT=&_WI_OBJECT_ID& FIELD_NAME='SUM_CURR')%

C

/SWL/ALL/DYNCO25 IBAN ORP at PO %/PE1/CL_FIORI_INBOX_DYN_ATTRS.GET_DYN_ATTR_VALUE_BY_OBJ(OBJECT=&_WI_OBJECT_ID& FIELD_NAME='SUM_CURR')%

C

/SWL/ALL/DYNCO26 Acct No. or IBAN ORP

%/PE1/CL_FIORI_INBOX_DYN_ATTRS.PI_ACCT_NO_OR_IBAN_ORP(OBJECT=&_WI_OBJECT_ID& FIELD_NAME='')%

C


User Interface


/SWL/ALL/DYNCO27 Acct No. or IBAN RCP

%/PE1/CL_FIORI_INBOX_DYN_ATTRS.PI_ACCT_NO_OR_IBAN_RCP(OBJECT=&_WI_OBJECT_ID& FIELD_NAME='')%

C

/SWL/ALL/DYNCOL1 Trans. Type %/PE1/CL_FIORI_INBOX_DYN_ATTRS.GET_DYN_ATTR_VALUE_BY_OBJ(OBJECT=&_WI_OBJECT_ID& FIELD_NAME='TRANS_TYPE')%

C

/SWL/ALL/DYNCOL2 Tech. Status %/PE1/CL_FIORI_INBOX_DYN_ATTRS.GET_DYN_ATTR_VALUE_BY_OBJ(OBJECT=&_WI_OBJECT_ID& FIELD_NAME='TECH_STAT')%

C

/SWL/ALL/DYNCOL3 PO Type %/PE1/CL_FIORI_INBOX_DYN_ATTRS.GET_DYN_ATTR_VALUE_BY_OBJ(OBJECT=&_WI_OBJECT_ID& FIELD_NAME='PO_TYPE')%

C

/SWL/ALL/DYNCOL4 Order Number %/PE1/CL_FIORI_INBOX_DYN_ATTRS.GET_DYN_ATTR_VALUE_BY_OBJ(OBJECT=&_WI_OBJECT_ID& FIELD_NAME='PO_NO')%

C

/SWL/ALL/DYNCOL5 Item Number %/PE1/CL_FIORI_INBOX_DYN_ATTRS.GET_DYN_ATTR_VALUE_BY_OBJ(OBJECT=&_WI_OBJECT_ID& FIELD_NAME='PI_NO')%

C



/SWL/ALL/DYNCOL6 Format %/PE1/CL_FIORI_INBOX_DYN_ATTRS.GET_DYN_ATTR_VALUE_BY_OBJ(OBJECT=&_WI_OBJECT_ID& FIELD_NAME='IN_OUT_FORMAT')%

C

/SWL/ALL/DYNCOL7 Medium %/PE1/CL_FIORI_INBOX_DYN_ATTRS.GET_DYN_ATTR_VALUE_BY_OBJ(OBJECT=&_WI_OBJECT_ID& FIELD_NAME='MEDIUM')%

C

/SWL/ALL/DYNCOL8 Channel %/PE1/CL_FIORI_INBOX_DYN_ATTRS.GET_DYN_ATTR_VALUE_BY_OBJ(OBJECT=&_WI_OBJECT_ID& FIELD_NAME='CHANGE')%

C

/SWL/ALL/DYNCOL4 Transaction Currency

%/PE1/CL_FIORI_INBOX_DYN_ATTRS.GET_DYN_ATTR_VALUE_BY_OBJ(OBJECT=&_WI_OBJECT_ID& FIELD_NAME='TR_CURR')%

C


User Interface

25 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 ToolsPerformance .

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 365

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 329] and Connection to an Account Management System [page 134].

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 367] and Accrual [page 369].

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 371].

Correspondence


Periodic Processing

Report Transaction

Start Correspondence Printing /PE1/PRINT_CORR

Display Correspondence /PE1/ERROR_CORR

For more information, see Correspondence (FS-PE-COR) [page 374].

25.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.


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 369] and Reconciliation [page 371].


More Information

Process Flow of End-of-Day Processing [page 368]

Connection to an Account Management System [page 134]

25.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

NoteIf 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.

NoteThis 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 325] and Final Processing (Collectors/Queues) [page 327].

NoteYou define closing criteria for collectors and queues in the clearing agreement. For more information, see Clearing Agreement [page 186].

4. You create reconciliation evaluation reports. For more information, see Reconciliation [page 371].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 369].


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.

25.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 368].


1. You increase the reconciliation date: The system sets the reconciliation date to the next business day.

ExampleThe 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.

ExampleTen 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.

ExampleThe 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.

ExampleThe 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 processingThe system creates an accrual order for each payment item that is to be accrued.

NoteAn 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 66].

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.

ExampleThe final reconciliation date is increased from April 6, 2009 to April 7, 2009.


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.

ExampleThe 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 329]

25.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 255].

● Clearing ProcessingFor more information, see Clearing Processing (FS-PE-CP) [page 302].

● Account Management ProxyFor more information, see Account Management Proxy (FS-PE-AMP) [page 329].

Prerequisites

● You have defined clearing areas in Customizing for Payment Engine by choosing Basic SettingsOrganization Define Clearing Area .


● 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)

NoteReconciliation 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 statusRepresents 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 itemsPayment items forwarded to an external system by Output Manager for conversion

○ Outgoing payment items transferred to an account management system● Grouping of payment orders based on:

○ Clearing area


Periodic Processing

○ 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 systemYou 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.

NoteWe 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 407].


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 368]

Connection to an Account Management System [page 134]

25.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 ComponentsGeneral 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 231]. For example, you can


Periodic Processing

create correspondence for different recall types. The system distinguishes between customer recalls and bank recalls. For more information, see Recall Management [page 112].

● 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 302].

● Determine whether correspondence is necessary during enrichment and validation. For more information, see Enrichment and Validation [page 276].

● Create correspondence for SEPA payment transactions.

More Information


Display Correspondence [page 378]


25.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 367].

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 .


http://help.sap.com/disclaimer?site=http%3A%2F%2Fwww.sdn.sap.com%2Firj%2Fsdn

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 .

NoteTo 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 223].


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.


Activities

To access this report, on the SAP Easy Access screen, choose Payment Engine Periodic ProcessingCorrespondence Start Correspondence Printing (transaction /PE1/PRINT_CORR).

More Information

Correspondence (FS-PE-COR) [page 374]

Display Correspondence [page 378]

25.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 375].

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

Output control


Periodic Processing

● 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 ProcessingCorrespondence Display Correspondence (transaction /PE1/ERROR_CORR).

More Information

Correspondence (FS-PE-COR) [page 374]



26 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 ToolsLogs 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 logRecords 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 logRecords 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 logSearches 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

NoteThis function is for expert users only.


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).

26.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 381

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.

NoteOnce 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 LogsPerformance Cockpit Start Performance Cockpit .

● To delete old logging data, choose Payment Engine Logs Performance Cockpit Delete Old Logging Data .


Logs

27 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 ordersFor more information, see Release Object ORDER (Payment Order) [page 103].

● Payment itemsFor more information, see Release Object POITEM (Payment Item) [page 108].

● RecallsFor more information, see Release Object RECALL (Recall) [page 116].

Master Data

● Service level agreementsFor more information, see Release Object SLA (Service Level Agreement) [page 228].

● Value date agreements and corresponding rulesFor more information, see Release Object VA (Value Date Agreement) [page 219].

● Routes and corresponding rulesFor more information, see Release Object ROUTE (Route) [page 182].

● Clearing agreements and corresponding rulesFor more information, see Release Object CA (Clearing Agreement) [page 195].

● Customer agreements and corresponding rulesFor more information, see Release Object CUSTAGR (Customer Agreement) [page 206].

● Exception control rulesFor more information, see Release Object EH (Exception Control Rule Set) [page 246].

Payment Engine (FS-PE)Release Workflow PUBLIC 383

28 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) .


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 386].

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.

384 PUBLICPayment Engine (FS-PE)Archiving (FS-PE-ARC)

Features

The following archiving tasks are available for Payment Engine (FS-PE):

● Customizing archiving functionsYou can make use of a number of functions to modify or to expand the archiving functions provided.

● Archiving and deleting payment dataYou can archive payment orders, payment items, and recalls using the Archive Administration (transaction SARA).

● Archiving other dataYou can archive application logs, change data, and service level agreements (SLAs).

● Viewing archived dataYou 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 386]

Archiving, deleting, and displaying payment data

(including payment items and collectors)

Archiving Payment Data [page 388]

Archiving logs and other data Archiving Logs and Documents [page 402]

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)

28.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 385

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 ComponentsSAP Information Lifecycle Management.

28.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 ManagementIf 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 388].

More Information

Archiving Payment Data [page 388]


http://help.sap.com/disclaimer?site=http%3A%2F%2Fhelp.sap.com%2Ferp

Archiving Logs and Documents [page 402]

28.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.


28.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 402]

28.3 Archiving Payment Data

Use

You can use this process to archive, delete, and display payment orders and recalls in Payment Engine.

NoteAll 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.


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_CUSTYou 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.

NoteThe residence time is calendar independent and can be maintained in days, weeks, months, or years.

○ Business checkThe 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.


ExampleUsing 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 391].● 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 phaseThis phase is used to read the written archive files and delete the corresponding database table entries.

NoteThe system does not delete payment items and payment-item dependent tables in this phase.

For more information, see Deleting Payment Items [page 400].

For more information, see Archiving Payment Orders [page 391] .

Archiving Recalls

The system uses only one archiving object for recalls, recall archiving (/PE1/RCL).

Recall archiving comprises these phases:

● Analysis phaseDuring the analysis, the system checks the residence time and performs the business checks.

● Write phaseAll recall entries (in table /PE1/DB_RECALL) are written to archive files.

● Delete phaseThe system reads the written archive file and deletes the corresponding database table entries.

NoteThe system does not delete payment items and payment-item dependent tables in this phase.


For more information, see Archiving Recalls [page 393].

Displaying Payment Orders and Archived Data

You can view payment orders in the archiving application.

For more information, see Displaying Payment Orders [page 401].


28.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 274].

NoteThe system handles payment items and collectors as part of the referenced payment order.

For more information, see Collector [page 311].

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).

NoteThe 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).


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.

NotePayment items referenced by multiple payment orders cannot be deleted until all referencing payment orders have been archived.


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).

NoteTo ensure that all available options appear, press Enter.


2. You can archive payment data from the following tables:

Table Content Available Activities

/PE1/DB_ORDER_AR Archiving payment orders (technical orders including splits)

Archive and delete

/PE1/DB_ORDER Payment orders in Payment Engine (headers)

Archive and delete

/PE1/DB_FH_ORDER File Handler payment order information

Archive and delete

/PE1/DB_FH_ORD_C Cluster table of File Handler payment orders

Archive and delete

/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 (headers)

Archive only

/PE1/DB_ACCR_DET Detail table of accruals Archive only

/PE1/DB_PAYM_REM Payment remittances in Payment Engine (headers)

Archive only

/PE1/DB_FH_ITEM File Handler payment-item information

Archive only

/PE1/DB_FH_ITM_C Cluster table of File Handler payment items

Archive only

/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.

28.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


For more information, see Recall Processing [page 115].

Using archiving object /PE1/RCL (Payment Engine: Order Analysis), the system can archive data listed in table /PE1/DB_RECALL.

NoteThe 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 CheckThe 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 CheckArchiving 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)


● 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


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.

28.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.


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 393].

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 118].

28.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


The system checks that the following applies before it archives collector categories or queue categories:

● The residence time specified has elapsed.

NoteYou 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 .

28.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 388].

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.


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)


● Last Date of SLA Validity (/PE1/DTE_PO_VALID_TO)

28.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.


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)


● Change Date (/PE1/DTE_BPE_CHDAT)


28.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.


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)


● LAST_CHANGE_DATE Type /PE1/DTE_BPE_CHDAT

Related Information


28.3.8 Archiving Value Date Data

You archive value dates and value date agreements using the archiving object /PE1/VA.



Value date data is assigned to ILM object PE1_VA. The following condition field is available:




Related Information



28.3.9 Archiving Routes and Clearing Agreement Data

You archive routes and clearing agreement data using the archiving object /PE1/RN.



Value date data is assigned to ILM object PE1_RN. The following condition field is available:




Related Information


28.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 391].

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 391].

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.

28.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

NoteYou 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.

3. Choose Extras Change Data Source Archive .For more information, see Edit Payment Orders (Expert) [page 338].

● 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 112].

● For information about how to display data that is archived in the File Handler Database, see Display File Handler Database [page 264].

28.4 Archiving Logs and Documents

Use

You archive application logs, change documents, and service-level agreements (SLAs) in the Archive Development Kit (ADK) [page 388] 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 403].

● Archive change documents (transaction /PE1/CHDOC_AR_ARCH)For more information, see Archiving Change Documents [page 403].

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.4. Execute the selected action.

28.4.1 Archiving Application Logs

Use

You archive application logs using the Archive Development Kit (ADK).


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.


28.4.2 Archiving Change Documents

Use

You archive change documents using the Archive Development Kit (ADK).


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.



29 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.

ExampleIf 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.

RecommendationWe 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 101].

● 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 106].

● Overview: Additional Information (transaction /PE1/RM_DISPLAY)Displays additional information about payment items, such as payment notes.

Payment Engine (FS-PE)Information System (FS-PE-IS) PUBLIC 405

● 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.


Information System (FS-PE-IS)

30 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.

30.1 Master Data

30.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)DataSources in SAP Payment Engine PUBLIC 407

http://help.sap.com/disclaimer?site=http%3A%2F%2Fhelp.sap.com%2Fpaymentengine

Extraction from Archives No

Verifiable No

Data Modeling

Fields of Origin for the Extraction Structure

Fields in the Extraction Structure

Description of the Field in 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

30.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






DataSources in SAP Payment Engine


Delta-Capable No


Verifiable No

Data Modeling




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

30.2 Flow Data

30.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


● OL_TYPE● IN_OUT_FORMAT● CHANNEL● TECH_STAT● CLEARING_AREA● FH_START_DATE● CRDAT● CHDAT● RECORDMODE

Technical Data






Delta-Capable Delta via snapshot on CHDAT


Verifiable No

Data Modeling

Delta UpdateThe CHDAT field is used for delta detection.

RecommendationWe 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.




OL_DATE OL Date /PE1/DB_OLIST OL_DATE





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

NoteThe CLEARING_AREA field is no key field for object lists.

30.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.


● CLEARING_AREA● PI_DATE


● 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






Delta-Capable No


Verifiable No

Data Modeling

Delta Update

The CHDAT field is used for delta detection.

RecommendationWe 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.







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 Number Range

/PE1/DB/ITEM PI_NO

SEGMENTATION_KEY Segmentation Criteria for DB Tables

/PE1/DB/ITEM SEGMENTATION_KEY

TECH_STAT Technical Status of Payment Item

/PE1/DB/ITEM TECH_STAT

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

30.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.


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.


● 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






Delta-Capable No




Verifiable No

Data Modeling

Delta Update

The CHDAT field is used for delta detection.

RecommendationWe 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.





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

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 / /

30.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






Delta-Capable Yes


Verifiable No



Data Modeling




AMOUNT_SUM Amount of Reconciliation Objects

/PE1/DB_RECONC AMOUNT_SUM

AM_AREA Account Managing Area /PE1/DB_RECONC AM_AREA

BS_KEY_NAME Key Name of Business System

Filled automatically 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 Objects

/PE1/DB_RECONC LAST_CHANGED

OBJECT_COUNT UTC Time Stamp in Short Form (YYYYMMDDhhmmss)

/PE1/DB_RECONC OBJECT_COUNT

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 of Various Areas, such as Internal Items

/PE1/DB_RECONC RECONC_CLUSTER

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 Mode



30.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.


Technical Data





RemoteCube-Capable Yes

Delta-Capable No


Verifiable No

Data Modeling




AMOUNT Amount in Transaction Currency

/PE1/DB_RECONC-AMOUNT AMOUNT_SUM

AM_AREA Account Managing Area /PE1/DB_RECONC AM_AREA





DEBCREDIND Debit or Credit /PE1/DB_RECONC TR_DEBCREDIND



RECONC_OBJ_ID Reconciliation Key /PE1/DB_RECONC RECONC_OBJECT

SYS_SPEC_OBJ_ID System-Specific Object ID for Reconciliation

/PE1/DB_ITEM CLEARING_AREA, PI_DATE, PI_NO




30.2.6 Payment Order Aggregated Data Extractor

0PE_PO_RECONC_AGGR_TRAN



Use


Using this DataSource, you can load aggregated reconciliation data for payment orders into the BI system.

Technical Data






Delta-Capable Yes


Verifiable No

Data Modeling










LAST_CHANGED Number of Reconciliation Objects

/PE1/DB_RECONC LAST_CHANGED

OBJECT_COUNT UTC Time Stamp in Short Form (YYYYMMDDhhmmss)








30.2.7 Payment Order Detailed Data Extractor

0PE_PO_RECONC_DETAIL_TRAN

Use


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





RemoteCube-Capable Yess

Delta-Capable No


Verifiable No

Data Modeling





/PE1/DB_RECONC_AMOUNT AMOUNT_SUM







RECONC_OBJ_ID Reconciliation Key /PE1/DB_RECONC RECONC_OBJECT





SYS_SPEC_OBJ_ID System-Specific Object ID for Reconciliation

/PE1/DB_RECONC, /PE1/DB_ORDER

CLEARING_AREA, PI_DATE, PI_NO




30.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


Exchange Available as of Release SAP Payment Engine 8.0




Delta-Capable Yes


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).


Data Modeling

Delta UpdateA delta update is supported: AIE After-Images Via Extractor





Filled automatically in extractor

Fixed value = space (After-Image





RECONC_ID Reconciliation Key /PE1/DB_RECONC Concatenation of RECONC_SYSTEM, RECONC_APPL, RECONC_ID

BUSINESS_AREA Business Area for Reconciliation

/PE1/DB_RECONC CLEARING_AREA

FLAG_CREDIT Credit flag /PE1/DB_RECONC TR_DEBCREDIND (TR_DEBCREDIND = D -> FLAG_CREDIT = <blank>, TR_DEBCREDIND = C -> FLAG_CREDIT = X


LAST_CHANGED Timestamp /PE1/DB_RECONC LAST_CHANGED

ITEM_SUM Amount of Reconciliation Objects


ITEM_CNT Number of Reconciliation 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=Ordering Party, 02=Recipient, 03=Clearing, 04=Turnover)

/PE1/DB_RECONC PI_KIND

OBJECT_CATG Reconciliation Object Type (Item/Order)


Fixed value = 02 (payment item)

Extractor LogicThe 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.



30.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






Delta-Capable Yes


Verifiable No

Data Modeling







Fixed value = space (After-Image)










/PE1/DB_RECONC Concatenation of 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)



Fixed value = 02 (payment item)

RECONC_OBJ_ID Reconciliation Object ID /PE1/DB_ITEM REF_ITEM_EXT

RECON_SYS_OBJ_ID System-Specific Object ID for Reconciliation

/PE1/DB_RECONC_D Concatenation of CLEARING_AREA, NUMBER_ID, OBJECT_DATE

CURRENCY Transaction Currency /PE1/DB_ITEM TR_CURR

AMOUNT Amount of Reconciliation Objects

/PE1/DB_ITEM TR_AMOUNT

Extractor LogicThe 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.

30.2.10 Reconciliation Hub: Payment Order Aggregated Data Extractor

0PE_RH_PAYMORDER_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 orders into the BI system.

Technical Data






Delta-Capable Yes


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







Fixed value = space (After-Image











LAST_CHANGED Timestamp /PE1/DB_RECONC LAST_CHANGED




OBJECT_CNT Number of Reconciliation Items




Fixed value = 01 (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.

30.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.



Technical Data






Delta-Capable Yes


Verifiable No

Data Modeling

Delta Update

A delta update is only possible when you upload all data.






Fixed value = space (After-Image)










Fixed value = 01 (payment order)

RECONC_OBJ_ID Reconciliation Object ID /PE1/DB_ORDER REF_EXT_PO

RECON_SYS_OBJ_ID System-Specific Object ID for Reconciliation

/PE1/DB_RECONC_D Concatenation of CLEARING_AREA, NUMBER_ID, OBJECT_DATE





Extractor LogicThe 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.

30.3 Texts

30.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






Delta-Capable No




Verifiable No

Data Modeling




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

30.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






Delta-Capable No


Verifiable No


Data Modeling




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

30.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






Delta-Capable No


Verifiable No



Data Modeling




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

30.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






Delta-Capable No


Verifiable No


Data Modeling




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

30.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






Delta-Capable No


Verifiable No



Data Modeling




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

30.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






Delta-Capable No


Verifiable No


Data Modeling




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

30.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






Delta-Capable No


Verifiable No



Data Modeling




LANGU Language key DD07T DDLANGUAGE

KEY1 Key field DD07T VALPOS

TXTLG Long text (length 60) DD07T DDTEXT

30.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






Delta-Capable No


Verifiable No


Data Modeling




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

30.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






Delta-Capable No


Verifiable No



Data Modeling




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

30.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






Delta-Capable No


Verifiable No


Data Modeling




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

30.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






Delta-Capable No


Verifiable No



Data Modeling




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

30.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






Delta-Capable No


Verifiable No


Data Modeling




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

30.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






Delta-Capable No


Verifiable No



Data Modeling




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

30.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






Delta-Capable No


Verifiable No


Data Modeling




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



Important Disclaimers and Legal Information

HyperlinksSome 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 a 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 PlatformsSome 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 FeaturesExperimental 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 CodeAny 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.

Gender-Related LanguageWe try not to use gender-specific word forms and formulations. As appropriate for context and readability, SAP may use masculine word forms to refer to all genders.

Payment Engine (FS-PE)Important Disclaimers and Legal Information PUBLIC 443

www.sap.com/contactsap

© 2020 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

https://www.sap.com/about/legal/trademark.html