Product Assistance for SAP S/4HANA Banking for payment

User Guide | PUBLICSAP Payment EngineDocument Version: 1.0 – 2020-07-10

Product Assistance for SAP S/4HANA Banking for payment centralization

© 2

020

SAP

SE o

r an

SAP affi

liate

com

pany

. All r

ight

s re

serv

ed.

THE BEST RUN

Content

1 SAP S/4HANA Banking for payment centralization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 End-to-End Payment Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Basic Cross-Border STP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.1 Cross-Border Payment Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4 Payment Processes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.1 Request for Cancellation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Active Request for Cancellation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22Passive Request for Cancellation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25

4.2 Recall of SEPA Credit Transfers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Active Recall of SEPA Credit Transfers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Passive Recall of SEPA Credit Transfers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.3 Cash Pooling with Request for Transfer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.4 Foreign Exchange (Overview). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Foreign Exchange Rates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.5 Batch Booking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.6 Card Transaction Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Authorization Request Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40Financial Request Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Authorization Reversal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5 Clearing Area. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6 Payment Order. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476.1 Release Object ORDER (Payment Order). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49

7 Payment Item. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527.1 Release Object POITEM (Payment Item). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

8 Recall. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568.1 Recall Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588.2 Recall Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 618.3 Release Object RECALL (Recall). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .628.4 Referential Data Interface (FS-PE-RDI). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Routing Directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65Standard Settlement Instructions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Bank Master Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71

2 PUBLICProduct Assistance for SAP S/4HANA Banking for payment centralization

Content

Account Substitution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

9 Request Agent. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

10 Connection of Internal and External Systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8110.1 Enterprise Services for Payment Centralization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Application Management Framework. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84Payment Transaction Order In/Event Out. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Payment Centralization Connector. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

10.2 Connection to an Account Management System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9410.3 FI Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9610.4 CML Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9710.5 Connection to an Embargo System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9810.6 Connection to a Liquidity Management System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

11 Master Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10111.1 Rule Set. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Determining Business Objects with Rule Sets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10311.2 Charges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Editing Charge Conditions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112Differentiation Categories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

11.3 Bank File Clearing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116Manage Bank File Clearing Accounts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

11.4 Routing Control (FS-PE-RP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119Route. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120Clearing Agreement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133Customer Agreement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145Value Date Agreement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

11.5 Service Level Agreement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170Managing Service Level Agreements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173Release Object SLA (Service Level Agreement). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175Status and Release Status of Master Data Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

11.6 Exception Control (FS-PE-EH). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .178Response Category. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180Response Type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .182Correction Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183Exception Control Rule Set. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185Foreign Exchange (FX). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197Processing of Active Returns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198Full Rejection of Payment Orders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .200Partial Rejection of Payment Orders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

12 File Handler (FS-PE-FH). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

Product Assistance for SAP S/4HANA Banking for payment centralizationContent PUBLIC 3

12.1 Input Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204Import File (Expert). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

12.2 Output Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20812.3 File Handler Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

Display File Handler Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21112.4 XML Converter Framework. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .212

ISO 20022 Converter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214ISO 8583 Converter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215SWIFT Converter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216

12.5 Financial Services Network Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21712.6 Eurogiro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21812.7 Notification of Payment Order Processing Status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

13 Payment Processing (FS-PE-POP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22113.1 Enrichment and Validation (FS-PE-EV). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

Check Processing Date. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .225Enrichment and Validation Check. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225Enrichment and Validation Check Set. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243Embargo Check. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245Enrichment and Validation for Outgoing Payment Orders. . . . . . . . . . . . . . . . . . . . . . . . . . . . .246

13.2 Routing Control Overview (FS-PE-RP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248

14 Clearing Processing (FS-PE-CP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25014.1 Queue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

Setting Up Queues and Collectors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255Managing Queues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

14.2 Collector. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259Setting Up Queues and Collectors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263Managing Customer Collectors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265Managing Clearing Collectors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

14.3 Direct Clearing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27014.4 Assign Payment Items to Collector/Queue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27114.5 Close Collector/Queue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27414.6 Final Processing (Collectors/Queues). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27614.7 Account Management Proxy (FS-PE-AMP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .277

Posting Simulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279Posting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281Reservation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .282Deletion of Reservation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

14.8 Alternative Clearing Scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284

15 User Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .285


Content

15.1 Payment Order. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285Edit Payment Orders (Expert). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286Create Payment (SAP Fiori). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295Create Payment Order (SAPUI5). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297Manage Payments (SAP Fiori). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .298Manage Waiting Payments (SAP Fiori). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298Display Payment Order (SAPUI5). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299

15.2 Exception Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .300Repair Payments (SAP Fiori). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300Exception Handling (SAPUI5). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302Manage Correction Rules (SAP Fiori). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302

15.3 Foreign Currency Trade Reporting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30315.4 Manage Payment Blocks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30415.5 Investigate Non-Financial Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30515.6 Payments Analyzer (SAP Fiori). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30615.7 Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306

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

16 Periodic Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31316.1 End-of-Day Processing (FS-PE-EOD). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315

Process Flow of End-of-Day Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316Accrual. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317Reconciliation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319

16.2 Correspondence (FS-PE-COR). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322Start Correspondence Printing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323Display Correspondence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326

17 Logs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32817.1 Performance Analysis in the Performance Cockpit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329

18 Release Workflow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331

19 Archiving (FS-PE-ARC). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33219.1 Maintaining Customizing Settings in Archiving Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33319.2 Archiving Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334

ILM Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335Archive Development Kit (ADK). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .336

19.3 Archiving Payment Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336Archiving Payment Orders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339Archiving Recalls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341Archiving Request Agents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .343Archiving Collector Categories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344Archiving Service Level Agreements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345


Archiving Object Lists. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346Archiving Bank File Clearing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347Archiving Value Date Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347Archiving Routes and Clearing Agreement Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348Deleting Payment Items. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348Displaying Payment Orders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .349

19.4 Archiving Logs and Documents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350Archiving Application Logs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351Archiving Change Documents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351

20 Information System (FS-PE-IS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .353

21 DataSources in SAP S/4HANA Banking for payment centralization. . . . . . . . . . . . . . . . . . . . 35521.1 Master Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355

Payment Order Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355Service Level Agreement Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356

21.2 Flow Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357Object List Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357Payment Item Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359Payment Order Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361Payment Item Aggregated Data Extractor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364Payment Item Detailed Data Extractor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365Payment Order Aggregated Data Extractor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .366Payment Order Detailed Data Extractor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368Reconciliation Hub: Payment Item Aggregated Data Extractor. . . . . . . . . . . . . . . . . . . . . . . . . 369Reconciliation Hub: Payment Item Detailed Data Extractor. . . . . . . . . . . . . . . . . . . . . . . . . . . . 371Reconciliation Hub: Payment Order Aggregated Data Extractor. . . . . . . . . . . . . . . . . . . . . . . . 372Reconciliation Hub: Payment Order Detailed Data Extractor. . . . . . . . . . . . . . . . . . . . . . . . . . . 374

21.3 Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376Format Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376PE Channel Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377Clearing Agreement Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378Clearing Area Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379Customer Agreement Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .379Object List Type Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380Payment Item Category Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381Payment Order Category Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382Payment Order Type Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383SLA Type Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384Service Level Agreement Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385Route Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386Segment Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .387


Content

Transaction Type Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388


1 SAP S/4HANA Banking for payment centralization

Use

SAP S/4HANA Banking for payment centralization 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.

SAP S/4HANA Banking for payment centralization 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

SAP S/4HANA Banking for payment centralization 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, SAP S/4HANA Banking for payment centralization 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, SAP S/4HANA Banking for payment centralization 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 17].

Thanks to its parallel-processing capability and its scalability, SAP S/4HANA Banking for payment centralization 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

SAP S/4HANA Banking for payment centralization 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 277], Connection of External Systems [page 81], and Archiving (FS-PE-ARC) [page 332].

The figure below shows a basic landscape example of SAP S/4HANA Banking for payment centralization and the flow of payment information.


SAP S/4HANA Banking for payment centralization

SAP S/4HANA Banking for payment centralization Overview

Features

Processing Functions

SAP S/4HANA Banking for payment centralization 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 SAP S/4HANA Banking for payment centralization in both batch mode (files) from feeder systems and online mode (messages) over the payment order interface.For more information, see Input Manager [page 204].

● Upload of referential dataSAP S/4HANA Banking for payment centralization 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 63].

● Format conversionSAP S/4HANA Banking for payment centralization 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

Product Assistance for SAP S/4HANA Banking for payment centralizationSAP S/4HANA Banking for payment centralization PUBLIC 9

processed. Outbound converters convert processed payment data to external payment data formats, for example, for export in an outgoing file.For more information, see File Handler (FS-PE-FH) [page 202] and File Handler Database [page 210].

● Enrichment and validationBased on checks for accuracy, consistency, and errors, SAP S/4HANA Banking for payment centralization 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 221], Enrichment and Validation [page 223], and Standard Settlement Instructions (SSI) [page 68].

● Routing controlSAP S/4HANA Banking for payment centralization 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. SAP S/4HANA Banking for payment centralization 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 119] and Charges [page 106].

● Clearing and settlementSAP S/4HANA Banking for payment centralization 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 250].

● Forwarding of payment ordersSAP S/4HANA Banking for payment centralization 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 208].

Monitoring and Control Functions

SAP S/4HANA Banking for payment centralization provides the following functions to monitor and control the payment processing workflow:

● Payment order managementSAP S/4HANA Banking for payment centralization 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 286] and Recall Management [page 58].

● Exception handlingSAP S/4HANA Banking for payment centralization 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 178].

● Other functionsSAP S/4HANA Banking for payment centralization can run periodic tasks, such as end-of-day processes and correspondence. You can view logged events, run reports, and evaluate business data. SAP S/4HANA


SAP S/4HANA Banking for payment centralization

Banking for payment centralization uses the user-management, authorization, and authentication mechanisms provided by SAP NetWeaver.For more information, see Periodic Processing [page 313], Logs [page 328], and Information System [page 353].

Product Assistance for SAP S/4HANA Banking for payment centralizationSAP S/4HANA Banking for payment centralization PUBLIC 11

2 End-to-End Payment Processing

Use

This process covers the payment processing workflow in SAP S/4HANA Banking for payment centralization: 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 15].

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 SAP S/4HANA Banking for payment centralization.For more information, see File Handler (FS-PE-FH) [page 202].

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 SAP S/4HANA Banking for payment centralization metaformat, and stores the payment order in the SAP S/4HANA Banking for payment centralization database.

NoteAny information or fields in the original payment order that are not required for processing in SAP S/4HANA Banking for payment centralization 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 210] and Input Manager [page 204].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 221] and Enrichment and Validation [page 223].


End-to-End Payment Processing

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 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, SAP S/4HANA Banking for payment centralization 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 119].

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

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 SAP S/4HANA Banking for payment centralization.

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 SAP S/4HANA Banking for payment centralization 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.

Product Assistance for SAP S/4HANA Banking for payment centralizationEnd-to-End Payment Processing PUBLIC 13

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.

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


End-to-End Payment Processing

3 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 Centralization 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 Centralization Master Data Service Level Agreements Manage Service Level Agreement(transaction /PE1/SLA). For more information, see Service Level Agreement [page 170] and Managing Service Level Agreements [page 173].

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

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

Process

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

Product Assistance for SAP S/4HANA Banking for payment centralizationBasic Cross-Border STP PUBLIC 15

2. The system converts the MT103+ message to the Payment Centralization metaformat.3. To ensure that the information in the MT103+ message is mapped to the Payment Centralization

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 SAP S/4HANA Banking for payment centralization 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 68].

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

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

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 SAP S/4HANA Banking for payment centralization 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 227].

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

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

3.1 Cross-Border Payment Processing

Concept

SAP S/4HANA Banking for payment centralization 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 12].

SAP S/4HANA Banking for payment centralization 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 63] and Standard Settlement Instructions (SSI) [page 68].

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

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


4 Payment Processes

Use

SAP S/4HANA Banking for payment centralization 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 20]● Recall of SEPA Credit Transfers [page 27]● Cash Pooling with Request for Transfer [page 35]● Foreign Exchange (FX) [page 197]

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

SAP S/4HANA Banking for payment centralization 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 202].

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

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

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

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

More Information

Active Request for Cancellation [page 22]

Passive Request for Cancellation [page 25]

Product Assistance for SAP S/4HANA Banking for payment centralizationPayment Processes PUBLIC 21

4.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 SAP S/4HANA Banking for payment centralization in Customizing for Payment Centralization 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 Centralization 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 Centralization by choosing Recall Management Maintain Valid-To Date .

● You have defined response types for external returns in Customizing for Payment Centralization by choosing Exception Control Define Response Types Response Types: Payment Item Define Response Types to Trigger External Returns .

● You have determined how SAP S/4HANA Banking for payment centralization responds to return messages sent from an account management system in Customizing for Payment Centralization by choosing

Posting Interfaces DM Proxy [or] BCA Proxy Return Determine Responses to AM Return Messages .

● You have mapped the return reasons defined in SAP S/4HANA Banking for payment centralization to the return reasons defined in the connected account management system in Customizing for Payment Centralization 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 Centralization 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.


Payment Processes

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 entire payment order, you must create a recall for each recipient item manually. For more information about creating recalls, see Recall Management [page 58].

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

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

6. The account management system uses the reference account information to create the payment items and sends the items back to SAP S/4HANA Banking for payment centralization 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 94].

6. The account management system uses the reference account information to create the payment items and sends the items back to Payment Centralization 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 Centralization 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 Centralization 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


Payment Processes

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.

More Information

Request for Cancellation [page 20]

Passive Request for Cancellation [page 25]

4.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 Centralization. To do this, in Customizing for Payment Centralization choose File Handler Process Integration Format ConverterMap 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 Centralization 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 Centralization by choosing Recall Management Maintain Valid-To Date .

● You have defined response types for internal returns in Customizing for Payment Centralization by choosing Exception Control Define Response Types Response Types: Payment Item Define Response Types to Trigger Internal Returns .

● You have determined how Payment Centralization responds to return messages sent from an account management system in Customizing for Payment Centralization 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 Centralization to the return reasons defined in the connected account management system in Customizing for Payment Centralization 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 204].

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


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

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

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

More Information

Request for Cancellation [page 20]

Active Request for Cancellation [page 22]


Payment Processes

4.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 Centralization 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 28].

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

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

For more information about routing recalls through third-party financial institutes, see Customizing for Payment Centralization, 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)

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

Periodic 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 Centralization (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 Centralization (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 198].


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 Centralization 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 78].

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


4.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 20].○ 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 CentralizationPeriodic 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 78].

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



Payment Processes

4.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 Centralization 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 Centralization, 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 Centralization 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 Centralization has implemented an outbound converter to send pain.014 to other financial institutions or customers. The request status is triggered by the existing Payment Centralization function of sender notification, which is available at Service Level Agreement level.

SWIFT-Converter:

● MT101 (Request for Transfer)


4.4 Foreign Exchange (Overview)

SAP S/4HANA Banking for payment centralization 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 S/4HANA Banking for payment centralization 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 Centralization under Basic SettingsForeign 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 197]Foreign Currency Trade Reporting [page 303]

4.4.1 Foreign Exchange Rates

There are a number of places where foreign exchange rates are displayed or can be entered in SAP S/4HANA Banking for payment centralization.

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

● Exchange rates entered and stored in SAP NetWeaver tables


Payment Processes

For currency conversions, SAP NetWeaver uses the following formulas to calculate an amount in target currency:○ Direct Quotation:

Rate * 1 unit of company currency = 1 unit of foreign currency○ Indirect Quotation:

Rate * 1 unit of foreign currency = 1 unit of company currencyThese rates are stored with up to 5 decimal points

● Exchange rates entered in SAP S/4HANA Banking for payment centralization, for example in Foreign Currency Trade Reporting.For currency conversions, SAP S/4HANA Banking for payment centralization 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 S/4HANA Banking for payment centralization 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 S/4HANA Banking for payment centralization 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 S/4HANA Banking for payment centralization 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 S/4HANA Banking for payment centralization in remittance types.

Related Information

Foreign Currency Trade Reporting [page 303]

4.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 S/4HANA Banking for payment centralization 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 225]

Service Level Agreement [page 170]

Alternative Clearing Scenarios [page 284]


Payment Processes

4.6 Card Transaction Processing

Use

SAP S/4HANA Banking for payment centralization covers real-time channels such as card transaction processing through web services.

Payment Centralization 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 S/4HANA Banking for payment centralization. Payment Centralization 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 S/4HANA Banking for payment centralization there are synchronous and asynchronous web services available (see Enterprise Services for Payment Centralization [page 83]). The switch can either consume the business services and directly create and process a payment order (also see Payment Transaction Order In [page 85]) or recall (see Action Payment Transaction Order [page 88]). Alternatively, the payment centralization connector (see Payment Centralization Connector [page 91]) 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 217]).

SAP S/4HANA Banking for payment centralization provides input converter for ISO 8583 messages using the payment transaction connector (see Payment Centralization Connector [page 91]).

More Information

Authorization Request Processing [page 40]

Financial Request Processing [page 41]

Authorization Reversal [page 42]


4.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 S/4HANA Banking for payment centralization. As a result, Payment Centralization 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 S/4HANA Banking for payment centralization containing multiple items of category 05 – Reservation Request. Upon processing the order, the order STP process follows (see Payment Processing (FS-PE-POP) [page 221]) 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 Centralization 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 215]


Payment Processes

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



4.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 56]). 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 178].



Activities



More Information


Recall [page 56]


Payment Processes

5 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 Centralization, 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 315].

● 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 Centralization 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 Centralization in a data center to control the processes in each clearing area separately.

The clearing area plays an important role in most Payment Centralization 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 Centralization under Basic SettingsOrganization Define Clearing Area .

Product Assistance for SAP S/4HANA Banking for payment centralizationClearing Area PUBLIC 43

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 Centralization under Basic Settings Organization Assign Bank Key to Clearing Area and Contract Partner .

Usually, one clearing area in Payment Centralization 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 Centralization under Basic Settings Account Management Systems Define SAP AM Bank Posting Area . For more information about the accrual and reconciliation processes, see Accrual [page 317] and Reconciliation [page 319].


Clearing Area

Example

A bank models its Payment Centralization 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 Centralization 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.

Product Assistance for SAP S/4HANA Banking for payment centralizationClearing Area PUBLIC 45

Example 2: Modeling of clearing areas


Clearing Area

6 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 Centralization by importing a file. For more information, see File Handler (FS-PE-FH) [page 202].

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

Furthermore, you can process payment orders in batch using the Poller report. To run this report, on the SAP Easy Access screen, choose Payment Centralization 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 223].

You make these settings in Customizing for Payment Centralization 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 Centralization under Payment Order Maintain Number Ranges of Payment Order .

● Payment order dateThe system retrieves the payment order date based on the reconciliation date defined in Payment Centralization.

Product Assistance for SAP S/4HANA Banking for payment centralizationPayment Order PUBLIC 47

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

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

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 Centralization or imported from a file for processing by Payment Centralization. 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 Centralization or imported from a file for processing by Payment Centralization. The route determines that the payment is external and after processing in Payment Centralization, 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 Centralization under Payment Order Release for Payment Order . For more information, see Release Workflow [page 331] and Release Object ORDER (Payment Order) [page 49].

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 Centralization 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 170].


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

6.1 Release Object ORDER (Payment Order)

Definition

A release object in Payment Centralization 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 Centralization 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 47]

Edit Payment Orders (Expert) [page 286]


7 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 Centralization by importing a file. For more information, see File Handler (FS-PE-FH) [page 202].

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

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 Centralization Periodic ProcessingProcesses Execute Processes (transaction /PE1/POLLER).

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

A payment item typically has one of the following statuses:

● 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 Centralization, 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 Centralization under Basic Settings Text Modules . You can also define the text that is attached to new payment items that are generated in Payment Centralization in Customizing for Payment Centralization 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 Centralization 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 Centralization Periodic Processing End-of-Day Processing Set PE Reconciliation Date Set Reconciliation Date (transaction /PE1/EOD_SET_DATE).

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

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 Centralization 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 223].

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 Centralization under Payment Items Release for Payment Item . For more information, see Release Workflow [page 331] and Release Object POITEM (Payment Item) [page 54].

Product Assistance for SAP S/4HANA Banking for payment centralizationPayment Item PUBLIC 53

7.1 Release Object POITEM (Payment Item)

Definition

A release object in Payment Centralization 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 Centralization under Payment Items Release 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 52]


Product Assistance for SAP S/4HANA Banking for payment centralizationPayment Item PUBLIC 55

8 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 61]. For more information about requests for cancellation, see Request for Cancellation [page 20].

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

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

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

You can define the attributes that are required, optional, and additional in recalls in Customizing for Payment Centralization 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 58].

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.

Product Assistance for SAP S/4HANA Banking for payment centralizationRecall PUBLIC 57

8.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 Centralization database when you activate a recall or during processing by an enrichment and validation check. For more information, see Enrichment and Validation [page 223].

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

○ 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 Centralization 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 Centralization by choosing Recall Maintain Automatic/Manual Recall Processing Indicator .

● You have specified further recall processing options in Customizing for Payment Centralization 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 12].

Checks

When you create new recalls, the system checks the following:

● Whether you have entered the required data as defined in Customizing for Payment Centralization, 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 178].

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


Recall

Recall Processing [page 61]

Active Recall of SEPA Credit Transfers [page 28]

Passive Recall of SEPA Credit Transfers [page 32]

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

Recall processing involves:

● Submitting recalls to Payment Centralization● 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 Centralization. For more information, see Recall Management [page 58].

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 Centralization under Tools Functional Monitoring Display Status Transitions Display Status Transitions of Recalls .

1. You manually upload a recall document to Payment Centralization or Payment Centralization 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 178].

More Information

For more information, see the following documentation:

● Recall [page 56]● Recall Management [page 58]● Enrichment and Validation [page 223]● Active Recall of SEPA Credit Transfers [page 28]● Passive Recall of SEPA Credit Transfers [page 32]

8.3 Release Object RECALL (Recall)

Definition

A release object in Payment Centralization 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 Centralization 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 56].

8.4 Referential Data Interface (FS-PE-RDI)

Use

You use this component to upload referential data made available by external data providers to Payment Centralization and to manage this data. Payment Centralization 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 Centralization Referential Data Upload Referential Data (transaction /PE1/UPLOAD_RD). For more information, see:○ Upload of Referential Data [page 66]○ Upload of Referential Data (SSI) [page 69]○ Upload of Referential Data (Bank Master Data) [page 72]

● Map provider-dependent referential data to a generic data structure and store the data in Payment Centralization

● Validate the structure of referential data uploaded to Payment Centralization● Display and edit referential data

On the SAP Easy Access screen, choose Payment Centralization 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 74].● Display business partners

On the SAP Easy Access screen, choose Payment Centralization 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.


Recall

More Information

Routing Directory [page 65]

Standard Settlement Instructions (SSI) [page 68]

Bank Master Data [page 71]

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

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 66]. The system maps the information to a generic data structure defined in Payment Centralization. You can access the stored data on the SAP Easy Access screen by choosing Payment CentralizationReferential Data Routing Directory Manage Routing Directory Data (transaction /PE1/MN_ROUTDIR). During the routing process, this data is used to route payment transactions to eligible financial institutions.

More Information

Routing Control (FS-PE-RP) [page 119]

8.4.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 Centralization under File HandlerBasic Settings Maintain Clearing System Identifications .

● You have implemented the Business Add-In BAdI: Retrieval of Clearing Systems in Customizing for Payment Centralization 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.


Recall

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 Centralization 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 65].

Activities

● To access this report, on the SAP Easy Access screen, choose Payment Centralization 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 Centralization Referential Data Routing DirectoryManage Routing Directory Data (transaction /PE1/MN_ROUTDIR).

Example

Full Upload

You want to upload a file that is based on the SEPA data model that contains routing information related to financial institutions that participate directly in the SEPA Direct Debits (SDD) payment scheme. In Data Model, you choose SDD direct. You obtained the file from the Euro Banking Association, so in Data Provider, you choose EBA.

The database contains no routing data and the file contains a large number of data records. In Max. Package Size, you enter 3000 to reduce the number of data records that the system processes. The system splits the


total number of records into smaller packages and then repeats the uploading process for all packages until all packages have been processed.

More Information

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

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


Recall

Integration

You upload information for standard settlement instructions from an external file. For more information, see Upload of Referential Data [page 69]. The system maps the information to a generic data structure defined in Payment Centralization. You can access the stored data on the SAP Easy Access screen by choosing Payment Centralization 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 Centralization 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 223]. 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 178].

More Information


8.4.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 Centralization by choosing Referential Data Standard Settlement Instructions (SSI) Define the Priority of SSI Attributes .


Features


Selection

Referential data


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

Activities


● To display, check, and, if necessary, change the data in the routing directory records you uploaded, on the SAP Easy Access screen choose Payment Centralization 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


Recall

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


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

Payment Centralization 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 74].

More Information


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


Recall

Features


Selection

Referential data


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

Activities


● To display, check, and, if necessary, change the bank master data records you uploaded, on the SAP Easy Access screen choose Payment Centralization 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


8.4.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 Centralization 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 Centralization. For more information, see Upload of Referential Data (Bank Master Data) [page 72].

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


Recall

● 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 Centralization Referential DataBank Master Data Generate Business Partners (Offline) (transaction /PECROSS/BP_GEN).

● To display business partners on the SAP Easy Access screen choose Payment CentralizationReferential Data Bank Master Data Display Business Partners (transaction /PECROSS/BP_BANK).

More Information

Bank Master Data [page 71]


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


Recall

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

Recipient Item Checks [page 235]


9 Request Agent

Definition

This object enables you to monitor a particular process that can involve subprocesses, both in Payment Centralization 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.

Product Assistance for SAP S/4HANA Banking for payment centralizationRequest Agent PUBLIC 79

Integration

You can call the report that lists the current request agents from the SAP Easy Access menu by choosing Payment Centralization 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 28]● Passive Recall of SEPA Credit Transfers [page 32]● Archiving Object /PE1/RAG [page 343]● For more information about Customizing settings related to the request agent, see Customizing for

Payment Centralization, under Request Agent .


Request Agent

10 Connection of Internal and External Systems

Use

Payment Centralization 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 Centralization 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 Centralization [page 83].

The following figure shows an example of a system landscape for Payment Centralization including an account-management system (AMS).

Payment Centralization Overview

For more information about the communication between Payment Centralization and external feeder systems and forwarding systems, see File Handler (FS-PE-FH) [page 202].

You can also submit payment transaction data from external systems in online mode over the payment order interface.

Product Assistance for SAP S/4HANA Banking for payment centralizationConnection of Internal and External Systems PUBLIC 81

The following figure shows the potential integration of Payment Centralization in the front end and middleware as well as possible real-time or other interfaces across the SAP NetWeaver integration and application platform.

Payment Centralization Integration

Prerequisites

You connect external systems through proxy or application programming interfaces (APIs) that require implementation of Business Add-Ins (BAdIs).

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

For more information, see Connection to an Embargo System [page 98].○ 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.


Connection of Internal and External Systems

3. You carry out applicable activities in Customizing for Payment Centralization.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 SAP NetWeaver platform.

Payment Centralization Extensions and Interfaces

10.1 Enterprise Services for Payment Centralization

Use

Payment Centralization 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 Centralization, 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

10.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 S/4HANA Banking for payment centralization Customizing ( Payment Centralization 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 106]

10.1.2 Payment Transaction Order In/Event Out

Use

Payment Centralization provides a new online interface for payment orders.

More Information

● Payment Transaction Order In [page 86]● Payment Transaction Order Event Out [page 90]

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

10.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 223]). 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 Centralization under File Handler

Financial Message Service Integration Control Payment Order Process .



It provides multiple operations:○ Create only: Processing of the order is done in batch (see Payment Processing (FS-PE-POP) [page

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

and Validation (FS-PE-EV) [page 223].○ 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 221].○ Immediate Processing: The order is processed synchronously according to Payment Processing (FS-

PE-POP) [page 221] 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 Centralization under BAdIs for Enterprise Services BAdIs for Business Object PaymentTransactionOrderBAdI 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.

10.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 Centralization under Basic Settings BAdIs for Enterprise Services BAdIs for Business Object PaymentTransactionOrder BAdI for PaymentTransactionProcessingPaymentTransactionOrderActionIn .


More Information

For more information, see the business object.

10.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 Centralization under Basic Settings BAdIs for Enterprise ServicesBAdIs for Business Object PaymentTransactionOrder BAdI for PaymentTransactionProcessingQueryPaymentTransactionOrderIn .


More Information

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

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

10.1.2.3 Payment Transaction Order In

New Service 9.0

10.1.2.4 Payment Transaction Order Out

10.1.3 Payment Centralization Connector

Use

SAP S/4HANA Banking for payment centralization 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 Centralization 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 92]

Payment Connector Out [page 93]

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


10.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 Centralization 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 Centralization 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 78].

● 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 Centralization 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 39]).

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

10.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 Centralization under Basic Settings BAdIs for Enterprise Services BAdIs for Business Object PaymentTransactionMessage BAdI for Create Message Out .


10.2 Connection to an Account Management System

Use

You can connect Payment Centralization 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 Centralization 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 Centralization 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 Centralization under Basic Settings Account Management SystemsBAdI: Customer-Specific Change of Payment Items (AM) .

● You have set up the AM Proxy in Customizing for Payment Centralization 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 Centralization 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 Centralization 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 Centralization by modeling your implementations on this process.

You can also use enterprise services for communication between Payment Centralization and an AMS. For more information, see Enterprise Services for Payment Centralization [page 83].

Integration of Account Management (FS-AM)

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

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


You can connect Bank Customer Accounts (IS-B-BCA) as an account management system to Payment Centralization to be able to transfer external postings from Bank Customer Accounts (IS-B-BCA) to Payment Centralization. It is then possible to perform the following tasks:

● Post items or simulate posting from Payment Centralization to Bank Customer Accounts (IS-B-BCA)● Reserve items in BCA● Store asynchronous posting responses in BCA● Process asynchronous BCA posting responses in Payment Centralization● Set up report-based reconciliation with BCA

For information, see SAP Note 1860880 .

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

More Information

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

10.3 FI Integration

Use

You can connect Payment Centralization to an SAP S/4HANA Financials (FI) system to enable postings from Payment Centralization 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 Centralization 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 Centralization transaction type to an account symbol in the Customizing activity

Assign PE Trans.Types to Account Symbols.● Create an RFC connection to an SAP S/4HANA Financials system in Customizing for Payment

Centralization under Basic Settings Account Management Systems as follows.



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

○ 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 Centralization to SAP S/4HANA and then create an FI document.

You can view the FI document in SAP S/4HANA using transaction FB03.

10.4 CML Integration

Use

You can integrate Payment Centralization with Consumer and Mortgages Loans (CML) in SAP S/4HANA. The converters used for CML integration are based on the XML format converter framework.

Integration

The integration of Payment Centralization with Consumer and Mortgages Loans (CML) supports the following scenarios:

● Credit transfer from CML to Payment Centralization.○ The SAP S/4HANA 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 Centralization by using the XML converter with

message identifier /CMLINT_CT.○ The file import generates a payment order that is processed by Payment Centralization.

● Direct debit from CML to Payment Centralization.○ The SAP S/4HANA 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 Centralization by using the XML converter with

message identifier /CMLINT_DD.○ The file import generates a payment order that is processed by Payment Centralization.

● Return of credit transfer from CML to Payment Centralization○ The SAP S/4HANA 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 Centralization by using the XML converter with message identifier /CMLINT_CT_RET.

○ The file import generates a payment order that is processed in Payment Centralization.● Transfer payment information from Payment Centralization to CML

1. Payment Centralization 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 S/4HANA 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 Centralization 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 Centralization under File Handler Process Integration Format Converter .

10.5 Connection to an Embargo System

Use

You can connect Payment Centralization to an available external embargo system to check embargo-relevant payment data that you send to an embargo system for processing.

Payment Centralization 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 Centralization under Payment Order Business Add-Ins (BAdIs)○ BAdI: Implementation of User Methods for Payment Order○ BAdI: Implementation of User Methods for Payment Item



● You have defined embargo system responses that determine whether payment items require exception handling and you have mapped these responses to Payment Centralization responses. You do this in Customizing for Payment Centralization 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 Centralization by modeling your implementations on this process.

More Information

Embargo Check [page 245]

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

10.6 Connection to a Liquidity Management System

You can connect SAP S/4HANA Banking for payment centralization 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 Centralization 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 Centralization under Basic Settings Local Application Management Systems Define Local Application Management Areas .


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

● You have defined the rules for the notification to be sent to the liquidity management system. You do this in Customizing for Payment Centralization under Payment Order Payment Order Enrichment and Validation Check Specific Configuration Maintain Rules for Liquidity process .

● To transfer the liquidity information, you can create an RFC connection or use a file-based approach for the internal or external system.



11 Master Data

Use

You can manage the following master data objects in Payment Centralization.

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

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

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

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

● The master data information stored in Payment Centralization 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 250].

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

Features

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

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

Product Assistance for SAP S/4HANA Banking for payment centralizationMaster Data PUBLIC 101

● All manual changes to master data (or transactional data) that occur within Payment Centralization 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 130]

11.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 103].

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 Centralization 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 116]



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

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


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 Centralization Master Data Bank File ClearingManage Bank File Clearing Accounts

● Rule sets for routes, clearing agreements, and customer agreements:On the SAP Easy Access screen, choose Payment Centralization Master Data Routing ControlManage Routes and Clearing Agreements .

● Rule sets for value date agreements:On the SAP Easy Access screen, choose Payment Centralization Master Data Routing ControlManage Set of Rules for Value Date .

● Rule set for the instruction code check:On the SAP Easy Access screen, choose Payment Centralization Master Data Service Level Agreements Manage Service Level Agreements Submission Data

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

● Rule sets for charge conditions:On the SAP Easy Access screen, choose Payment Centralization Master Data Service Level Agreements Manage Service Level Agreements Charges

● Rule set for exception handlings:On the SAP Easy Access screen, choose Payment Centralization Master Data Exception ControlDefine 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 Centralization 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 102].

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.

11.2 Charges

SAP S/4HANA Banking for payment centralization 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 S/4HANA Banking for payment centralization 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 Centralization, 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 Centralization supports the following scenarios:

Payment of Charges - Scenarios Supported by SAP S/4HANA Banking for payment centralization

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 S/4HANA Banking for payment centralization 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 Centralization 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 Centralization 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 Centralization 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 S/4HANA Banking for payment centralization

ID Charge Process Used For

001 Payment Order Submission Can be used if you submit a payment in SAP S/4HANA Banking for payment centralization 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 S/4HANA Banking for payment centralization;

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 Centralization 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 112]Differentiation Categories [page 114]Basic Cross-Border STP [page 15]

11.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 S/4HANA Banking for payment centralization uses charge processing rule sets created in the service level agreement to calculate and process charges.


Master Data

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

want it to apply only to specific charge (sub-)processes, specify these restrictions in the left panel of the Rule Maintenance popup.

c. If you want to assign the charges to the receiver, choose Charge Bearer – Receiver). If not, leave the field blank and choose OK.

6. For Charge Settlement choose Set of Rules.

A Charge Settlement section opens:

a. Click on the Create Rule Set icon to enter a new rule. A Rule Maintenance appears.


b. If you want the rule to apply only to payment orders /payment items with particular attributes, or if you want it to apply only to specific charge (sub-)processes, specify these restrictions in the left panel of the Rule Maintenance popup.

c. Charge Account Details: Add the criteria you want to use to determine the correct internal accounts to be used for posting charges.

Results

You have defined charge conditions and can now assign the charges to the corresponding service level agreements and clearing agreements.

Related Information

Charges [page 106]Differentiation Categories [page 114]Service Level Agreement [page 170]

11.2.2 Differentiation Categories

Use

In SAP S/4HANA Banking for payment centralization you can use differentiation categories to help determine the correct conditions to use for calculating charges.

SAP S/4HANA Banking for payment centralization provides the following differentiation categories:

Differentiation Categories available in SAP S/4HANA Banking for payment centralization

Description

D01 BIC

D02 Charge Type

D03 Transaction Type

D04 Payment Order Type

D05 STP Capability

D07 Recall Type

D08 Return Reason


Master Data

Description

D09 Recall Group

D10 Number Recipient Items

D12 Medium

D13 Channel

D14 Format

D20 Status Notification Template ID

D21 Status Notification Type ID

D30 Product

D31 Product Group

D32 Instruction Code

D33 Currency Group

D34 Country Group (Recipient)

D35 Country (Recipient)

D36 Account Type

Activities

You can manage differentiation categories in Customizing for Payment Centralization under Basic SettingsCharges Define Differentiation Categories .

To assign condition categories to them in Customizing, go to Payment Centralization Basic SettingsCharges Assign Condition Categories to Differentiation Categories .

More Information

Charges [page 106]

Editing Charge Conditions [page 112]


11.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 223].

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


Master Data

● Bank identifier code (BIC) of recipient● Name of the recipient of the payment order

Information for clearing and settlement

● Settlement method● Clearing system ID

Information about the clearing account

● Bank identifier code (BIC)● Bank key● Bank country● Account number● Account currency● IBAN● Account holder

Indicator for separate provision of cover

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


More Information

Manage Bank File Clearing Accounts [page 118]

11.3.1 Manage Bank File Clearing Accounts

Use

You use this function to manage bank master data that Payment Centralization 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 Centralization by choosing Basic SettingsOrganization Define Clearing Area .

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

● You have defined clearing system IDs in Customizing for Payment Centralization 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 227] and Payment Order Checks [page 228].

Activities

To manage bank file clearing accounts, on the SAP Easy Access screen, choose Payment CentralizationMaster Data Bank File Clearing Manage Bank File Clearing Accounts (transaction /PE1/MN_BFC_N).

More Information



Master Data

11.4 Routing Control (FS-PE-RP)

Use

This component determines the relevant business objects for the further processing of payment items. These business objects contain information that is necessary to transfer money from one financial institution to another. During route processing, the system analyzes each payment item to evaluate how it should be processed and links various business objects to each payment item by using flexible rule sets.

First, the system analyzes whether a payment is internal (the beneficiary is a customer of the financial institution processing the payment) or external (the beneficiary is not a customer of the financial institution processing the payment).

The system analyzes internal payments to evaluate whether there is a special agreement with the beneficiary, such as the instruction to collect certain payments instead of posting every single payment item to an account. If a financial institution uses different account management applications for different lines of business, the system locates the relevant account management application.

The system analyzes external payments to evaluate the preferred outgoing channel or payment method. These channels or methods can be used to forward payments to local or international clearing systems or the appropriate financial institutions.

In Routing Control, the following business objects are relevant:

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

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

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

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

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 221]● Enrichment and Validation [page 223]● Clearing Processing (FS-PE-CP) [page 250]

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


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 Centralization 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 Centralization 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 331].

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

● Externally


Master Data

The beneficiary is not a customer of the financial institution processing the payment. A route serves externally to determine the clearing institute for outgoing payment orders.

A route is determined for each payment item and additionally groups clearing agreements.

Use

Internal routes define which account management area and therefore which account management system is relevant for a certain internal beneficiary of a payment item or for a certain ordering party of a payment item. If a financial institution has two or more internal account management systems, the correct account management system for a particular situation is found. For internal payments items, the system first searches for a customer clearing agreement. If no customer clearing agreement is found, the system searches for a standard internal clearing agreement. Both agreements are directly linked to an internal route.

External routes roughly classify the direction of external payments. External clearing agreements are linked to external routes.

You can set a lock for outgoing processing on the route level, meaning that the processing of outgoing payments for all clearing agreements assigned to the route is temporarily blocked. This lock could be used, for example, to temporarily stop all forwarding of U.S. dollar payments. As a result, the system does not generate any outgoing payment orders for any channel assigned to this route until you cancel the lock.

The system analyzes the route rule set in one clearing area and thereby considers only active routes. If a new route is in processing or for release, the old route is still active. As soon as the new route is released, the old route is replaced by the new route. For more information about the release workflow, see Release Workflow [page 331].

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 178]. 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 Centralization Master Data Routing Control Manage Routes and Clearing Agreements (transaction /PE1/RN). For more information, see Managing Route Rule Sets [page 123] and Managing Route Rules [page 125].

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 tree


Displays existing routes, clearing agreements, and customer agreements in a hierarchical structure.● Business object

Displays details about the selected route, clearing agreement, or customer agreement organized on tab pages.

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


Master Data

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

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

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

11.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 Centralization 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 Centralization 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 125].

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.


Master Data

For more information about the screen areas on the route screen, see Route [page 120] under Structure.

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

3. Make the required changes.You can create, change, and delete rules in the rule set. Furthermore, you can activate or deactivate rules in the rule set.For more information, see Managing Route Rules.

4. Save the object and trigger the release process by choosing the Release pushbutton.

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.

11.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 Centralization 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 120] 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.


Master Data

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


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.

11.4.1.3 Release Object ROUTE (Route)

Definition

A release object in Payment Centralization 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 Centralization under Routing Control Release 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.


Master Data


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

Structure

You can edit release object ROUTE as a work item in the Business Workplace. These methods can affect the status of the route. For more information, see Status and Release Status of Master Data Objects [page 130].

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

11.4.1.4 Status and Release Status of Master Data Objects

When you edit the following master data objects in SAP S/4HANA Banking for payment centralization, 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


Master Data

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

Status and Release Status of a Master Data Object

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

Related Information

Release Object SLA (Service Level Agreement) [page 175]Release Object ROUTE (Route) [page 128]Release Object CA (Clearing Agreement) [page 141]Release Object CUSTAGR (Customer Agreement) [page 153]Release Object CAGRASS (Assignment of General Customer Agreement) [page 155]


Release Object EH (Exception Control Rule Set) [page 193]Foreign Exchange (FX) [page 197]

11.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 Centralization:

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


Master Data

More Information

● For more information about bulking files for outgoing payments, see the report documentation. From the SAP Easy Access menu, choose Periodic Processing Processes Bulk Files for Outgoing Payments .

● For more information about bulking see Output Manager [page 208].● 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 78].

11.4.2 Clearing Agreement

Definition

An object that specifies the conditions for the transfer of payment orders within or between financial institutions (internal or external clearing agreement).

A clearing agreement includes the following parameters:

● Whether and how payment items are transferred individually or collectively● How payment information is exchanged● How the transaction value is procured

Each financial institution involved in the payment transaction has at least one clearing agreement with another clearing institute.

Use

You can use clearing agreements to specify how the system processes internal and external payment items.

The system analyzes the clearing agreement rule set in one clearing area and considers only active clearing agreements. If a new clearing agreement is in processing or for release, the old clearing agreement is still active. As soon as the new clearing agreement is released, the old clearing agreement is replaced by the new clearing agreement. For more information about the release workflow, see Release Workflow [page 331].

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 178]. 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 Centralization Master Data Routing Control Manage Routes and Clearing Agreements (transaction /PE1/RN). For more information, see Managing Clearing Agreement Rule Sets [page 136] and Managing Clearing Agreement Rules [page 138].

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


Master Data

On this tab page, you can define the basic processing characteristics of your clearing agreement. Based on the selection of the available attributes, additional data and tabs become available.

The screen is divided into different sections:

● Clearing Scenario○ Collection (opens an additional Collector Process tab)○ Clearing Time○ Individual Advice (only for internal clearing agreements; opens an additional Customer Advice

Information tab)○ Alternative Processing Options (opens an additional Customer Advice Information tab)

● Forwarding Options○ Forward Directly for outgoing order based processing; the order is directly forwarded to the File

Handler component○ Lock Outgoing Payments

● Value Dating○ Value Date Ruleset ID

● Alternative Clearing used, for example, for scenarios in which the clearing agreement is locked or in case of other alternative scenarios in order to control further transaction processing

External Clearing Agreement

This tab page is displayed only for external clearing agreements.

Note● Account Symbol field

Since an account symbol can be used for several clearing agreements, it is easier to change the account to be used by maintaining the account symbol instead of modifying several clearing agreements. You can maintain account symbols in Customizing for Payment Centralization under

Clearing Define and Maintain Account Symbols .● Execution On checkbox

If you choose this option, the following fields are displayed:○ Base time

Specifies the date that the system uses to calculate the planned execution time of payment transactions. If you choose the due date, the system uses the due date to calculate the planned execution time of direct debit transactions and the planned closing time of the collector that collects the corresponding payment items.

○ Markup/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 252] and Collector [page 259].

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

Customer Agreement [page 145]

Value Date Agreement [page 158]

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


Master Data

Prerequisites

To create, change, and delete a clearing agreement and its rule set:

● You have defined the release workflow in Customizing for Payment Centralization 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



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


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

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


Master Data

You can change the behavior in the clearing agreement determination by changing characteristics in the rule. You can only change clearing agreement rules by changing a clearing agreement.

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


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





Master Data


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.



11.4.2.3 Release Object CA (Clearing Agreement)

Definition

A release object in Payment Centralization 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 143].

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


Master Data

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


Status of the Clearing Agreement

Release Status Status of the Clearing Agreement

Release Status


More Information









Related Information



Master Data


11.4.3 Customer Agreement

Definition

A special agreement with a customer of a financial institution.

The customer agreement identifies the customer account or accounts that are relevant for the special agreement; or the accounts can be defined by a customer service level agreement (SLA) and this SLA refers to the customer agreement.

A customer agreement is used to group a set of internal clearing agreements (customer clearing agreements) that are associated with a specific customer. Customer agreements can be defined below internal routes only.

Use

By using customer agreements, you can identify certain payments for certain accounts that are to be collected before they are posted as one sum to an account. You can then provide the customer with an electronic advice showing the details of the sum that the system posted to the account.

You use a customer agreement to group a set of internal clearing agreements with an association to a customer. Customer agreements can be valid for one or more accounts of a customer:

● Specific customer agreement (type Other)In most cases, you manage this customer agreement directly for one or more accounts of a specific customer. The agreement is unique and cannot be used for other customers.

Customer clearing agreements created below an individual customer agreement are of clearing agreement type Internal: Individual Service Level Agreement.

You can manage both customer agreements and their rule sets and customer clearing agreements and their rules as follows:

On the SAP Easy Access screen, choose Payment Centralization Master Data Routing Control Manage Routes and Clearing Agreements (transaction /PE1/RN). For more information, see Managing Customer Agreement Rule Sets [page 147] and Managing Customer Clearing Agreement Rules [page 150].

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


Master Data

○ Flagged for deletion● Bank customer

You can use this field to assign a customer agreement to a specific customer.● Valid from and valid to

Indicates the validity of the customer agreement.● Assigned Accounts tab page

You can specify different accounts of a specific customer.

Customer Clearing Agreement

For more information about the structure of customer clearing agreements, see Clearing Agreement [page 133] 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 223] and Service Level Agreement [page 170].

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

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


Master Data

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

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



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.

11.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 Centralization 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:



Master Data

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






Changing Customer Clearing Agreement Rules

1. From the navigation tree, double-click a customer clearing agreement associated with the customer agreement rule set where you want to change a rule.

2. In change mode, you can change the customer clearing agreement in the business object screen area and the customer agreement rules in the rules screen area.For more information about the screen areas on the customer clearing agreement screen, see Customer Agreement under Structure.








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.




Master Data

11.4.3.3 Release Object CUSTAGR (Customer Agreement)

Definition

A release object in Payment Centralization 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 Centralization under Routing Control Release 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.

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

● Display


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

This pushbutton opens the dialog transaction Manage Routes and Clearing Agreements. The system closes the old release workflow and triggers a new release process with the changed data. The status of the new customer agreement release object is initially For Release. This method in the Business Workplace can change the status and release status of the customer agreement as follows:The system checks the changed item and generates a new work item if applicable and deletes the existing work item.

● Display change 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



Master Data

11.4.3.4 Release Object CAGRASS (Assignment of General Customer Agreement)

Definition

A release object in Payment Centralization 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 Centralization under Routing Control Release 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.


More Information






Master Data




Related Information




11.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 178]. 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.


Master Data

You can also carry out a value split for ordering party items, that is, instead of creating one posting, the system creates several items with corresponding value dates. The split is determined depending on the value dates of the recipient items.

You can manage value date agreements and their rule sets as follows:

On the SAP Easy Access screen, choose Payment Centralization 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 161] and Managing Value Date Agreement Rules [page 164].

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


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

● 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


Master Data

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

More Information

Route [page 120]


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


Prerequisites

To create, change, and delete a value date agreement and its rule set:

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




Master Data

Creating Value Date Agreement Rule

Create a value date agreement rule.

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


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


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.

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


Master Data

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


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.



11.4.4.3 Release Object VA (Value Date Agreement)

Definition

A release object in Payment Centralization 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.


Master Data

Use

Customizing


You make the settings for release object VA in Customizing for Payment Centralization 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 168].

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


● 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






Master Data




Related Information




11.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 S/4HANA Banking for payment centralization.

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


Master Data

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 S/4HANA Banking for payment centralization 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 S/4HANA Banking for payment centralization.

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

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

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

● Charges tab pageDisplays options to manage charges.


Master Data

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 S/4HANA Banking for payment centralization automatically triggers exception handling to evaluate the error and determine an appropriate response.

Related Information

Exception Control (FS-PE-EH) [page 178]Enrichment and Validation (FS-PE-EV) [page 223]Enrichment and Validation Check [page 225]

11.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 Centralization under Payment OrderSLA Release for SLA .

● You have the necessary rights to change and create an SLA for the selected clearing area.● You have defined the number range for SLAs for the selected clearing area in Customizing for Payment

Centralization under Payment Order SLA Maintain Number Ranges for SLAs .


Context

To manage SLAs, you can do the following:

● Display an existing SLA● Create a new SLA of any type (clearing area, customer segment, customer group, or customer)● Change an existing SLA● Delete an SLA

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 Centralization Master Data Service Level Agreements Manage Service Level Agreements (transaction /PE1/SLA), enter a clearing area, and continue.You can show or hide the search area and navigation tree by choosing the Switch Overview Tree On/Off pushbutton.

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 Centralization database where it is set to Flagged for Deletion when the archiving process takes place.

○ For more information, see Archiving (FS-PE-ARC) [page 332].


Master Data

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.

11.5.2 Release Object SLA (Service Level Agreement)

Definition

A release object in Payment Centralization 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 Centralization under Payment Order SLA Release 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.


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

● 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



Master Data

11.5.3 Status and Release Status of Master Data Objects







Related Information

Release Object SLA (Service Level Agreement) [page 175]Release Object ROUTE (Route) [page 128]Release Object CA (Clearing Agreement) [page 141]Release Object CUSTAGR (Customer Agreement) [page 153]Release Object CAGRASS (Assignment of General Customer Agreement) [page 155]Release Object EH (Exception Control Rule Set) [page 193]Foreign Exchange (FX) [page 197]

11.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 Centralization 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 Centralization are linked to Exception Control:

● File Handler (for Input Manager and Output Manager)For more information, see File Handler (FS-PE-FH) [page 202].

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

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


Master Data

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

Payment Centralization directly handles exceptions during payment processing using the payment order management transaction:

On the SAP Easy Access screen, choose Payment Centralization 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 288].

Features

If an error occurs in any of the Payment Centralization 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 Centralization 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 180] and Response Type [page 182].

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

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

If the response type causes the process in end-to-end payment processing to be continued, Exception Control ensures that the process continues from the correct position with the correct parameters. Depending on the response type, the object in question (payment order or payment item) can be resubmitted to end-to-end payment processing at different positions: Either directly from the position where the transfer took place or at the beginning of the process during end-to-end payment processing from which the transfer took place, for example, payment processing or clearing and settlement.


After the system performs the response, the system checks and determines the following:

● If the response has been performed successfully, processing within Exception Control ends for the business object in question.

● If it is not possible to perform a response, the system triggers an end response type to be carried out.

More Information

End-to-End Payment Processing [page 12]

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


Master Data

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

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

Response Categories for Payment Items

Payment Centralization 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 198].

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

● 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 Centralization 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 item authorization. For more information, see Enrichment and Validation [page 223].

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

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

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

Integration

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

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

11.6.2 Response Type

Definition

A user-definable identification feature to further specify the response of an exception based on the response category.


Master Data

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

You can define response types in Customizing for Payment Centralization 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 188].

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

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

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

11.6.3 Correction Rules

If you have set up an exception handling reaction type for manual postprocessing (for a payment order or payment item), you can set up your system in such a way that it analyzes the manual changes made during this processing step to see if it can detect recurring correction patterns that could potentially be automated.

If the system finds a correction pattern and this pattern is applied a predefined number of times, a correction rule is proposed automatically and can be looked up in the Fiori app Manage Correction Rules.

You can also choose to create correction rules manually.

Automatically Generated Correction Rules

All automatically proposed correction rules are based on corrections that have been repeatedly carried out manually. An algorithm detects the correction pattern. When the correction pattern has been (manually) applied a predefined number of times, a correction rule is generated.


You can also configure the system to submit orders/items corrected by a correction rule to be submitted to a release workflow for a certain number of times, before the correction rule becomes fully automatic.

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 S/4HANA Banking for payment centralization. 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.


Master Data

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 Centralization Basic Settings Local Application Management Systems Define Local Application Management Systems )

2. Assign it to the relevant clearing area( Payment Centralization Basic Settings Local Application Management Systems Define Local Application Management Areas )

2. Assign the application to the relevant response type for postprocessing.( Payment Centralization Exception Control Define Response Types Response Types: Payment Order Define Response Types for Postprocessing , or Payment Centralization Exception ControlDefine 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 Centralization Periodic Processing Exception Handling Postprocessing Learn Data-Automatic Postprocessing .

(Transaction /PE1/EH_AUTOPP)

4. Specify the following in Customizing under Payment Centralization 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.

11.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 Centralization, such as rule sets used in Routing Control for business objects (for example, routes and clearing agreements). For more information, see Rule Set [page 102].


Several Payment Centralization 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 188].

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 Centralization Master Data Exception Control Define Exception Control (transaction /PE1/EH).

For more information about the procedures, see Managing Exception Control Rules [page 191].

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 Centralization, which represents the different steps that payment orders or payment items go through during processing. Payment Centralization 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.


Master Data

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.


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 Centralization under

Exception Control Exception Handling Release for Exception Handling . For more information, see Release Workflow [page 331] and Release Object EH (Exception Control Rule Set) [page 193].

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

11.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 Centralization under Exception Control.

You have defined rule sets for exception control:

On the SAP Easy Access screen, choose Payment Centralization Master Data Exception Control Define Exception Control .

Features

Rule Determination

Several Payment Centralization 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


Master Data

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


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.


Master Data

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


11.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 Centralization under Exception Control in the corresponding Customizing activities.

● You have defined the release workflow in Customizing for Payment Centralization under Exception Control Exception Handling Release for Exception Handling .

To display an exception control rule:



Procedure

On the SAP Easy Access screen, choose Payment Centralization Master Data Exception Control Define Exception Control (transaction /PE1/EH) and select a clearing area.

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 185] 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:



Master Data



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.



11.6.4.3 Release Object EH (Exception Control Rule Set)

Definition

A release object in Payment Centralization 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



You make the settings for release object EH in Customizing for Payment Centralization under Exception Control Basic Settings for Exception Handling Release for Exception Handling in the following Customizing activities:


Channel

Dialog

Individual processing: transaction 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 195].

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

● ChangeChoosing this pushbutton brings you to the dialog transaction 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 Exception Control with dialog box Display Change Documents of the exception control rule set.

● Release


Master Data

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








Related Information



Master Data


11.6.5 Foreign Exchange (FX)

SAP S/4HANA Banking for payment centralization 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 235]

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


Related Information

Foreign Exchange (Overview) [page 36]Foreign Currency Trade Reporting [page 303]

11.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 Centralization 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 Centralization 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 Centralization under Payment Items Transaction Types and Transaction Type Groups Define Transaction Type Groups for Exception Control .

● You have defined a response type for active returns in Customizing for Payment Centralization 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 Centralization 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 .


Master Data

● You have mapped the formats required to create incoming messages and outgoing messages in Customizing for Payment Centralization 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 178].○ 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.


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

11.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 201].


Master Data

Prerequisites

● You have made the required setting in Customizing for Payment Centralization, 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.

11.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 Centralization, 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.


12 File Handler (FS-PE-FH)

Use

You use this component to manage the communication between Payment Centralization 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 Centralization for each combination of format, medium, and channel available. You can specify different options for transferring payment transaction data to and from Payment Centralization. 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 81].

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


File Handler (FS-PE-FH)

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 Centralization in batch mode in files. You can also submit single payment orders to Payment Centralization in online mode over a BAPI: the payment order interface, or a service. For more information on services, see Enterprise Services for Payment Centralization [page 83].

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

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

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

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

Product Assistance for SAP S/4HANA Banking for payment centralizationFile Handler (FS-PE-FH) PUBLIC 203

12.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 Centralization 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 221]. Payment transaction messages received by Payment Centralization are converted to the internal metaformat for clearing and settlement. For more information, see Routing Control (FS-PE-RP) [page 119] and Clearing Processing (FS-PE-CP) [page 250].

Prerequisites

● You have made the settings in Customizing for Payment Centralization, by choosing File Handler Basic Settings .

● You have made the settings for external references in Customizing for Payment Centralization, 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 Centralization, 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 Centralization. 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 Centralization. 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 58].

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 Centralization 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 Centralization, on the SAP Easy Access screen choose Payment Centralization 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 206].

● To display data stored in the File Handler database during processing, on the SAP Easy Access screen choose Payment Centralization File Handler Display File Handler Database (transaction /PE1/FH_SHOW_DB). For more information, see Display File Handler Database [page 211].

More Information


Output Manager [page 208]

File Handler Database [page 210]

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

12.1.1 Import File (Expert)

Use

You use this report to upload payment data from a feeder system to Payment Centralization. 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 Centralization, 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 204] 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 Centralization 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 286].

Output

In the Input Manager, the converters map the data received from the source system to the Payment Centralization metaformat. The system stores the data in the Payment Centralization 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 Centralization.

Activities

To access this report, on the SAP Easy Access screen choose Payment Centralization File Handler Import File (Expert) (transaction /PE1/FH_IPM_EXPERT).

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


12.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 119] and Clearing Processing (FS-PE-CP) [page 250].

Prerequisites

● You have made the settings in Customizing for Payment Centralization, 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 Centralization, 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 Centralization, by choosing File Handler File Handler Exception Handling .

● If required, you have made the settings to enrich output payment information, in Customizing for Payment Centralization 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 Centralization 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 Centralization 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 178].

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 Centralization 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 Centralization Payment Order Management Edit Payment Orders (Expert)(transaction /PE1/PO_EXPERT).

● To bulk outgoing payment files, make the required settings in Customizing for Payment Centralization, 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 204]


For more information about bulking, see the report documentation.

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

12.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 Centralization, regardless of whether this data is required for further processing of the payment transactions.



For more information, see Input Manager [page 204]. 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 Centralization 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 208].

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

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.

12.3.1 Display File Handler Database

Use

You use this report to display payment data sent by a feeder system to Payment Centralization that is stored in the File Handler database. This database stores all original payment data sent by the feeder system including data that Payment Centralization does not require to process payment transactions.

Integration

Payment Centralization stores all incoming payment transaction data in the File Handler database in its original format. After the necessary data has been processed, Payment Centralization includes this data in the outbound data in the target format.

Prerequisites

You have identified the number and date of creation in Payment Centralization 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 332]

Activities

To access this report, on the SAP Easy Access screen choose Payment Centralization File HandlerDisplay File Handler Database (transaction /PE1/FH_SHOW_DB).

More Information


12.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 Centralization (FS-PE) XML

converter input file (directory)○ Logical path: /PE1/XML_CONVERTER_INPUT_PATH Payment Centralization (FS-PE) XML converter

input path● Output Manager (OPM)

○ Logical filename: /PE1/XML_CONVERTER_OUTPUT_FILE Payment Centralization (FS-PE) XML converter output file (directory)

○ Logical path: /PE1/XML_CONVERTER_OUTPUT_PATH Payment Centralization (FS-PE) XML converter output path

○ Stream output classes: /PE1/CL_OPM_OUTPUT_STREAM Payment Centralization (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 Centralization.

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.

12.4.1 ISO 20022 Converter

Definition

SAP S/4HANA Banking for payment centralization 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


SWIFT Converter [page 216]

12.4.2 ISO 8583 Converter

SAP S/4HANA Banking for payment centralization 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

12.4.3 SWIFT Converter

SAP S/4HANA Banking for payment centralization 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 305].

12.5 Financial Services Network Integration

Use

SAP S/4HANA Banking for payment centralization provides the integration to the SAP Financial Services Network (FSN). This means that Payment Centralization 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 Centralization 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


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

12.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 Centralization. Choose File Handler Status Notification Define Notification Templates .

● You have defined status notification rules for the service level agreement by carrying out the following steps:

1. From the SAP Easy Access menu, choose Master Data Service Level Agreements Manage Service Level Agreements .



2. Select the service level agreement for which you want to define status notification rules.3. On the SLA General tab page, choose Correspondence.4. Go to the Correspondence tab page, choose Set of Rules, then choose Create Rule to create your own

rule definitions.

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 Centralization to a status notification status ID, for example, payment order status 173 (Rejected) to ISO status code RJCT. Payment transaction mapping in Payment Centralization conforms to SEPA regulations.

For more information, see Customizing for Payment Centralization under File Handler Status NotificationBusiness Add-Ins (BAdIs) BAdI: Adjustment of Payment Transaction Status for pain.002 .



13 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 Centralization 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 223].

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

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

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

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 Centralization Periodic Processing ProcessesExecute Processes (transaction /PE1/POLLER).

Product Assistance for SAP S/4HANA Banking for payment centralizationPayment Processing (FS-PE-POP) PUBLIC 221

● Display an overview of payment orders and payment items and manage payment orders and payment itemsOn the SAP Easy Access screen, choose Payment Centralization Payment Order Management Edit Payment Orders (Expert) (transaction /PE1/PO_EXPERT).For more information, see Edit Payment Orders (Expert) [page 286].

● 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 Centralization Master Data Service Level Agreements Manage Service Level Agreements (transaction /PE1/SLA).For more information, see Service Level Agreement [page 223] and Managing Service Level Agreements [page 173].

● 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 Centralization 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 58]. Payment Centralization also support the cancellation of SEPA Direct Debits (SDD). For more information, see .

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 Processing (FS-PE-POP)

13.1 Enrichment and Validation (FS-PE-EV)

Use

This process enables the attributes of payment orders and payment items to be validated in Payment Centralization 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 Centralization 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 178]. If an error is so severe that the internal repair function cannot correct it, Payment Centralization can call an external automatic repair function using an exception handling process.

Payment Centralization 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 Centralization, see Enrichment and Validation Check Set [page 243] and Enrichment and Validation Checking [page 227].

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 Centralization Master Data Service Level Agreements Manage Service Level Agreement


(transaction /PE1/SLA). For more information, see Service Level Agreement [page 170] and Managing Service Level Agreements [page 173].

Process

1. The system reads the payment orders that are pending processing in Payment Centralization.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 221]





13.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 Centralization 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 223]

13.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 Centralization 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 227].


You can define your own checks in Customizing for Payment Centralization 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 Centralization 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 178].

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 Centralization, 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 Centralization, choose

Payment Order Payment Order Enrichment and Validation Maintain Enrichment and Validation Check Sets .

More Information

Enrichment and Validation Check Set [page 243]

13.1.2.1 Enrichment and Validation Checking

Use

This function validates payment orders and payment items in Payment Centralization during the enrichment and validation process.

Prerequisites

● You have defined a check set and assigned a rule type in Customizing for Payment Centralization 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 Centralization 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 225].

The system performs validation checks at different levels. For more information, see:

● Payment Order Checks [page 228]● Ordering Party Item Checks [page 231]● Recipient Item Checks [page 235]● Cross Item Checks [page 239]

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

Enrichment and Validation Check [page 225]


13.1.2.1.1 Payment Order Checks

Use

You use these enrichment and validation checks to validate payment orders in Payment Centralization 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 227] under Prerequisites.



● You have defined a payment order type group for enrichment and validation in Customizing for Payment Centralization 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 Centralization 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 Centralization 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 Centralization.

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 Centralization

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

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

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

13.1.2.1.2 Ordering Party Item Checks

Use

You use these checks to validate ordering party items in Payment Centralization during the enrichment and validation process.

Prerequisites


● You have maintained the transaction type groups for enrichment and validation in Customizing for Payment Centralization 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 Centralization 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 Centralization 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 Centralization.

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

Centralization 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 Centralization un

der 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

Centralization 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 76].

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

Embargo Check: PI is Embargo Relevant

(CHECK_V_EMBARGO)

For information, see Embargo Check [page 245].

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





13.1.2.1.3 Recipient Item Checks

Use

You use these enrichment and validation checks to validate recipient items in Payment Centralization during the enrichment and validation process.

Prerequisites





Features

The following table describes the recipient item checks supported by Payment Centralization.

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

Centralization 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

Centralization 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 Centralization un

der 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

Centralization under SEPA Maintain SEPA Country

Check where 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 Centralization 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 76].

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

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




13.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 228] under Prerequisites.

● You have defined the Customizing settings for enrichment and validation of payment items. For more information, see Ordering Party Item Checks [page 231] or Recipient Item Checks [page 235] under Prerequisites.

Features

The following table describes the cross item checks supported by Payment Centralization.

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 Centralization

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 calculation in Customizing for Payment Centralization 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




13.1.2.1.5 Reservation Item Checks

Use

You use these enrichment and validation checks to validate reservation items in Payment Centralization during the enrichment and validation process.

Prerequisites






Features

The following table describes the recipient item checks supported by Payment Centralization.

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




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

You can define and assign names to the enrichment and validation check set rules and assign rules to check sets in Customizing for Payment Centralization under Payment Order Payment Order Enrichment and Validation Maintain Enrichment & Validation Check Sets .

Structure

An enrichment and validation check set has the following structure:

● Clearing areaSpecifies a legally independent organizational unit in Payment Centralization.

● 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 ORPThis rule contains only outgoing ordering party item checks.

○ Outgoing PO RCPThis rule contains only outgoing recipient item checks.

○ Outgoing PO CLRThis rule contains only outgoing clearing item.

● Enable/Disable indicatorDetermines 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 Centralization 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 Centralization under Payment Item Maintain Enrichment and Validation Check Sets Assign E&V Check Set for Payment Item .

More Information

Check Processing Date [page 225]

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


Prerequisites

Payment Centralization is connected to an embargo system over a Business Application Programming Interface (BAPI). For more information, see Connection to an Embargo System [page 98].

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

● If Payment Centralization sends a payment order or payment item to an embargo system, the embargo system performs the required check and sends a response to Payment Centralization 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 178].

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.

13.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 S/4HANA Banking for payment centralization 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 178].



Prerequisites

● You have defined E&V checks in Customizing for Payment Centralization under Payment OrderPayment 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 Centralization 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 227]


13.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 Centralization under Payment Item Payment Item Enrichment and Validation Maintain Error Threshold for Recipient Items . If the threshold is reached and the percentage or number of incorrect items exceeds the permitted limit, an exception is added to the payment order (error ID 000090). You can respond to this error in Exception Control (transaction /PE1/EH) under Outgoing Payment Order Processing Outgoing Payment Order Enrichment & Validation PO .

Exclude Recipient Items from Outgoing Payment Orders and Reprocess Items

You can exclude incorrect recipient items from outgoing payment orders. To do so, select the response Exclude RCP from Outgoing Order (EXCLUDE_PI) in Exception Control under Outgoing Payment Order 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


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



14 Clearing Processing (FS-PE-CP)

Use

You use this component for final processing of internal and external payment items during clearing and settlement.

Payment Centralization 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 221] and Routing Control (FS-PE-RP) [page 119].

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

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

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

NoteFor more information, see Direct Clearing [page 270].

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

● CollectionPayment Centralization 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 259].

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 Centralization 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 271].

● Close collectors and queuesFor more information, see Close Collector/Queue [page 274].

● Initiate final processing of collectors and payment items parked in queuesFor more information, see Final Processing (Collector/Queue) [page 276].

Product Assistance for SAP S/4HANA Banking for payment centralizationClearing Processing (FS-PE-CP) PUBLIC 251

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

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

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 Centralization 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 133] 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 Centralization under Clearing Maintain 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 CentralizationPeriodic Processing Processes Execute Processes (transaction /PE1/POLLER).



14.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 Centralization 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 133] 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 Centralization Master Data Routing ControlManage 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 133] 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 20].

○ 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 Centralization Clearing Manage Collectors and Queues (transaction /PE1/CP_COLL).



Next Steps

Queue [page 252]

Collector [page 259]

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

● You have defined the settings for queues. On the SAP Easy Access screen, choose Payment Centralization Master 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 Centralization 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 Centralization 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 252] 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 255].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 271]● Close Collector/Queue [page 274]● Final Processing (Collector/Queue) [page 276]

NoteYou can display an overview of status transitions for collectors and queues in Customizing for Payment Centralization under Tools Functional Monitoring Display Status Transitions Display Status Transitions of Collectors .

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

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 282], Posting Simulation [page 279], and Completing Mandates [page 294].

Payment Centralization 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 265].● 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 267].

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

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

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 133] 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 Centralization under Clearing Maintain 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.



14.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 Centralization 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 133] 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 Centralization Master Data Routing ControlManage 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 133] 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 20].

○ 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 Centralization Clearing Manage Collectors and Queues (transaction /PE1/CP_COLL).



Next Steps

Queue [page 252]

Collector [page 259]

14.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 Centralization under Clearing Define and Maintain Account Symbols .

You have defined the settings for customer collectors. On the SAP Easy Access screen, choose Payment Centralization 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 259] 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 133].

3. Switch to change mode and change the settings.For more information, see Setting Up Queues and Collectors [page 263].




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:



14.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 Centralization under Clearing Define and Maintain Account Symbols .

You have defined the settings for clearing collectors. On the SAP Easy Access screen, choose Payment Centralization 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 259] 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 133].

3. Switch to change mode and change the settings.For more information, see Setting Up Queues and Collectors [page 263].


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:



14.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 Centralization Master Data Routing Control Manage Routes and Clearing Agreements (transaction /PE1/RN).

For more information, see Clearing Agreement [page 133].

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 forwarded

3. If defined, the system calls up the credit-limit-check application to authorize a payment.4. After the authorization is received, the system sends a posting request to an internal account management

system.5. The internal account management system posts the payment to the beneficiary account.

Single-Item Forwarding of External Payment Items

1. After route processing, the system transfers payment items to Clearing Processing.2. Based on the settings in the route and the clearing agreement, the system determines the following:

○ That the payment items are external○ That the payment items are not to be assigned to a queue or collector○ The internal account management system to which the payment items are to be forwarded

3. Output Manager creates a new outgoing payment order in which the financial institution is the ordering party requesting the recipient (a clearing system or external financial institution) to execute the payment. Output Manager sends the outgoing payment order in a file. For more information, see Output Manager [page 208].

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.

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

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 Centralization Master Data Routing Control Manage Routes and Clearing Agreements(transaction /PE1/RN).

For more information, see Setting Up Queues and Collectors [page 255].

You have mapped the error codes of the account management system to the error codes used in Payment Centralization and specified the relevant error ID used in Exception Handling in Customizing for Payment Centralization 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 Centralization 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 61].



● 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 Centralization 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 Centralization Clearing Manage Collectors and Queues (transaction /PE1/CP_COLL).

● To assign payment items to a queue or collector automatically using a batch process, on the SAP Easy Access screen, choose Payment Centralization 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 Centralization 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 274]

Final Processing (Collectors/Queues) [page 276]


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



Prerequisites

You have defined the closing criteria: On the SAP Easy Access screen, choose Payment CentralizationMaster Data Routing Control Manage Routes and Clearing Agreements (transaction /PE1/RN).

Features

You can specify the following closing conditions for a particular queue category or collector category:

● Time-based closing 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 CentralizationClearing 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 Centralization Periodic ProcessingProcesses Execute Processes (transaction /PE1/POLLER).

More Information


Assign Payment Items to Collector/Queue [page 271]

Final Processing (Collectors/Queues) [page 276]


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

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 Centralization. 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 271].

● The collector or queue is closed. For more information, see Close Collector/Queue [page 274].● The conditions for processing are defined in the clearing agreement. For more information, see Setting Up

Queues and Collectors [page 255].● The clearing agreement is not locked before processing of the corresponding payment items starts. For

more information, see Clearing Agreement [page 133].● Payment Centralization is connected to an account management system. For more information, see

Connection to an Account Management System [page 94].



● You have mapped the error codes of the account management system to the error codes used in Payment Centralization and specified the relevant error ID used in Exception Handling in Customizing for Payment Centralization 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 Centralization 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 Centralization Periodic Processing Processes Execute Processes (transaction /PE1/

POLLER).

More Information


Assign Payment Items to Collector/Queue [page 271]

Close Collector/Queue [page 274]

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



You need to set up and configure Account Management Proxy and a connected AMS in Customizing for Payment Centralization. You can use the proxy-interface infrastructure to connect more than one AMS. For more information, see Connection to an Account Management System [page 94].

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

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

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 Centralization

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 279].● Posting [page 281].● Reservation [page 282].● Deletion of Reservation [page 283].

Reports

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

● Reconciliation of PE and AMProvides information about discrepancies between Payment Centralization 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 313].

14.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 Centralization, 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 270].

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 282] and Posting [page 281].

Prerequisites

Payment Centralization 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 94].

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

Logs [page 328]



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

Postings can usually be executed within a direct clearing scenario or within a collection scenario.

For more information, see Direct Clearing [page 270] and Collector [page 259].

Prerequisites

Payment Centralization 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 328]

14.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 270], Collector [page 259], Assign Payment Items to Collector/Queue [page 271], and Final Processing (Collectors/Queues) [page 276].

Prerequisites

Payment Centralization 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 328]

14.7.4 Deletion of Reservation

Use

This function deletes a reservation (prenote) when Payment Centralization 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 282].

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 Centralization 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 328]


14.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 214]. 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 38]



15 User Interface

Use

SAP S/4HANA Banking for payment centralization 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 285]Exception Handling [page 300]Foreign Currency Trade Reporting [page 303]Manage Payment Blocks [page 304]Investigate Non-Financial Messages [page 305]Payments Analyzer (SAP Fiori) [page 306]Release [page 306]

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

Product Assistance for SAP S/4HANA Banking for payment centralizationUser Interface PUBLIC 285

Related Information

Edit Payment Orders (Expert) [page 286]Create Payment (SAP Fiori) [page 295]Create Payment Order (SAPUI5) [page 297]Manage Payments (SAP Fiori) [page 298]Manage Waiting Payments (SAP Fiori) [page 298]Display Payment Order (SAPUI5) [page 299]

15.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 Centralization.● The payment orders and payment items have not been posted.● You have expert experience of processing payment transactions in Payment Centralization.

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

Activities

● To display, create, change, or reject payment orders and payment items, on the SAP Easy Access screen, choose Payment Centralization Payment Order Management Edit Payment Orders (Expert)(transaction /PE1/PO_EXPERT). For more information, see:○ Payment Order and Payment Item Overview [page 288]○ Creating Payment Orders and Payment Items [page 290]○ Changing Payment Orders and Payment Items [page 293]○ Completing Mandates [page 294]○ Deleting Payment Orders and Payment Items [page 292]

● To display archived payment orders, on the SAP Easy Access screen, choose Payment CentralizationPayment Order Management Edit Payment Orders (Expert) (transaction /PE1/PO_EXPERT). Choose

Extras Change Data Source Archive .● Change documents are available when payment orders or payment items are changed. You can access

change documents by choosing Extras Change Document Payment Order or Payment Item .


15.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 Centralization manually or that you have imported into Payment Centralization.

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 178].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 Centralization metaformat because it is not required for payment processing. For more information about the File Handler Database, see File Handler Database (FHDB) [page 210].

● 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 Centralization 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 Centralization 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 Centralization under Tools Functional MonitoringDisplay Status Transitions .

More Information


15.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 Centralization 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 Centralization under:

○ Payment Order Release for Payment Order

○ Payment Items Release for Payment Item

Procedure

1. On the SAP Easy Access screen, choose Payment Centralization 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 204] and Import File (Expert) [page 206].

More Information

Payment Order [page 47]


Payment Item [page 52]

15.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 Centralization 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 Centralization before payment processing begins.

Procedure

1. On the SAP Easy Access screen, choose Payment Centralization 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 288].

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 Centralization. The system no longer stores the payment order and its payment items in the Payment Centralization database and you can no longer access the rejected payment order or its payment items using any transactions for payment processing or postprocessing.

15.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 Centralization.● You have defined the release workflow in Customizing for Payment Centralization 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 Centralization, 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 Centralization 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 288].

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.

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

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

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

For more information about collectors, see Collector [page 259]

15.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 S/4HANA Banking for payment centralization 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 296]

15.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 in SAP S/4HANA Banking for payment centralization Customizing ( Payment Centralization 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 S/4HANA Banking for payment centralization Customizing:

Reconciliation Unit Create Payment Fiori App Parameter

System ID ReconSystem

Application ID ReconApplication

Additional ID of Reconciliation Unit ReconAdditionalId

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

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.

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


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


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

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


15.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 300]Exception Handling (SAPUI5) [page 302]

15.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 Centralization 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 Centralization Basic Settings Global Package Settings Maintain Global Technical Package Setting .)

● Print the order● Save as Template

Use this function to save all the details currently entered in the order, so that you can reuse them.● Recall Order (see "Recall")● Open PO Expert (see "Edit Payment Orders (Expert)")● Show File Handler Data

Use this function to display an extract showing the file handler data.● Show Original File

Use this function to display the complete file.


Related Information

Recall [page 56]Edit Payment Orders (Expert) [page 286]

15.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 Centralization under Exception Control Define Response Types .

Related Information

Repair Payments (SAP Fiori) [page 300]Exception Control (FS-PE-EH) [page 178]

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

15.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 Centralization 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 S/4HANA Banking for payment centralization 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 Centralization 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 36]

15.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 S/4HANA Banking for payment centralization under Post-Installation Tasks.


User Interface

15.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 Centralization 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 216].


15.6 Payments Analyzer (SAP Fiori)

In this SAP Fiori App, you can analyze your payments by displaying their key figures in different charts.


You can:

● Visualize payment information in tables or charts● Flexibly select key figures and time periods to be visualized● Filter and aggregate payments● Convert payment amounts ad hoc by choosing a different display currency● Save your visualization in a separate tile in your SAP Fiori Launchpad

15.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 S/4HANA Banking for payment centralization 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.

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


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

16 Periodic Processing

Use

You use certain reports and functions in Payment Centralization 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 Centralization under ToolsPerformance .

Features

You can run the following reports on the SAP Easy Access screen, by choosing Payment CentralizationPeriodic 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

Product Assistance for SAP S/4HANA Banking for payment centralizationPeriodic Processing PUBLIC 313

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 277] and Connection to an Account Management System [page 94].

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 315] and Accrual [page 317].

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

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

16.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 Centralization 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 317] and Reconciliation [page 319].


More Information

Process Flow of End-of-Day Processing [page 316]

Connection to an Account Management System [page 94]

16.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 Centralization 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 274] and Final Processing (Collectors/Queues) [page 276].

NoteYou define closing criteria for collectors and queues in the clearing agreement. For more information, see Clearing Agreement [page 133].

4. You create reconciliation evaluation reports. For more information, see Reconciliation [page 319].5. You create a report of any discrepancies between Payment Centralization 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 317].


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

16.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 Centralization under Clearing Define and Maintain Transaction Type Symbols .

● You have defined the settings for accrual in Customizing for Payment Centralization 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 316].


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

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 Centralization 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 277]

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

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

● Account Management ProxyFor more information, see Account Management Proxy (FS-PE-AMP) [page 277].

Technical RemarksThe aggregate table /PE1/DB_RECONC has been deprecated. All reconciliation sums are now calculated directly from the item and order source tables.


Prerequisites

● You have defined clearing areas in Customizing for Payment Centralization by choosing Basic SettingsOrganization Define Clearing Area .

● You have defined reconciliation settings in Customizing for Payment Centralization under Reconciliation by performing the following Customizing activities:○ Define Reconciliation Settings for Clearing Areas○ Assign Reconciliation Units to Converter Attributes

● To perform automatic reconciliation with an account management system, you have defined the settings in Customizing for Payment Centralization by choosing Reconciliation Business Add-Ins (BAdIs) BAdI: Configuration of Reconciliation Screens .

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 Centralization 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○ Reconciliation date


Periodic Processing

○ 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 Centralization 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 Centralization 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 Centralization, 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).

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 S/4HANA Banking for payment centralization [page 355].


Activities

To evaluate payment items for reconciliation purposes on the SAP Easy Access screen, choose Payment Centralization 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 316]

Connection to an Account Management System [page 94]

16.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 Centralization 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 178]. 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 58].

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

● Determine whether correspondence is necessary during enrichment and validation. For more information, see Enrichment and Validation [page 223].

● Create correspondence for SEPA payment transactions.

More Information

Start Correspondence Printing [page 323]

Display Correspondence [page 326]


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

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 Centralization 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 Centralization 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 Centralization by choosing Exception Control Define Response TypesResponse 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 Centralization by choosing Exception ControlDefine 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 Centralization 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 Centralization by choosing Exception Control Define Response TypesResponse 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 Centralization Master Data Service Level Agreements Manage Service Level Agreements (transaction /PE1/SLA). For more information, see Service Level Agreement [page 170].


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 Centralization Periodic ProcessingCorrespondence Start Correspondence Printing (transaction /PE1/PRINT_CORR).

More Information

Correspondence (FS-PE-COR) [page 322]

Display Correspondence [page 326]

16.2.2 Display Correspondence

Use

You use this report to display correspondence that has been created in Payment Centralization 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 323].

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


Periodic Processing

● Identification

Output control

● Maximum number of hits● Layout

Output

Depending on the layout settings you define, the following correspondence data can appear in the list:

● Correspondence type● Issue date and issue time

Date and time when a correspondence request was created● Print date

If applicable, date on which the correspondence was printed● Sender

Business partner that sends the correspondence● Original recipient

Business partner that receives the original correspondence● Contract account● Language in which you display and enter texts and print documents● Transaction currency in which document is or was posted● Amount of the payment transaction in the local currency● Account managing area● Correspondence recipient

Business partner to which correspondence is to be sent● Internal contract ID● Order party or recipient item reference number● Data type for which the system creates correspondence, for example, purchase order

Activities

To access this report, on the SAP Easy Access screen, choose Payment Centralization Periodic ProcessingCorrespondence Display Correspondence (transaction /PE1/ERROR_CORR).

More Information

Correspondence (FS-PE-COR) [page 322]

Start Correspondence Printing [page 323]


17 Logs

Use

You can display logs for monitoring business objects and processes in Payment Centralization.

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 Centralization under Tools Logs Define Group Settings for Functional Log .

● You have defined the messages you want the functional log to record in Customizing for Payment Centralization 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 Centralization 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 Centralization LogsDisplay Technical Log (transaction /PE1/TECHLOG).

● To display the functional log, on the SAP Easy Access screen, choose Payment Centralization LogsDisplay 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 Centralization 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 Centralization Logs Administration Settings Manage Log Settings (transaction /PE1/

LOG_SETTINGS).

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

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

Tools Performance Activate Performance Cockpit for Applications .

Product Assistance for SAP S/4HANA Banking for payment centralizationLogs PUBLIC 329

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 Centralization LogsPerformance Cockpit Start Performance Cockpit .

● To delete old logging data, choose Payment Centralization Logs Performance Cockpit Delete Old Logging Data .


Logs

18 Release Workflow

Use

You can use this function to trigger a release workflow whenever certain objects within Payment Centralization 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 49].

● Payment itemsFor more information, see Release Object POITEM (Payment Item) [page 54].

● RecallsFor more information, see Release Object RECALL (Recall) [page 62].

Master Data

● Service level agreementsFor more information, see Release Object SLA (Service Level Agreement) [page 175].

● Value date agreements and corresponding rulesFor more information, see Release Object VA (Value Date Agreement) [page 166].

● Routes and corresponding rulesFor more information, see Release Object ROUTE (Route) [page 128].

● Clearing agreements and corresponding rulesFor more information, see Release Object CA (Clearing Agreement) [page 141].

● Customer agreements and corresponding rulesFor more information, see Release Object CUSTAGR (Customer Agreement) [page 153].

● Exception control rulesFor more information, see Release Object EH (Exception Control Rule Set) [page 193].

Product Assistance for SAP S/4HANA Banking for payment centralizationRelease Workflow PUBLIC 331

19 Archiving (FS-PE-ARC)

Use

You use this component to remove data that is no longer required in Payment Centralization 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 Centralization are preconfigured for archiving payment data. In Customizing for Payment Centralization, 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 334].

Integration

In archiving, business objects are represented as archiving objects. The Payment Centralization 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.


Archiving (FS-PE-ARC)

Features

The following archiving tasks are available for Payment Centralization:

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

Archiving, deleting, and displaying payment data

(including payment items and collectors)

Archiving Payment Data [page 336]

Archiving logs and other data Archiving Logs and Documents [page 350]

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)

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

Product Assistance for SAP S/4HANA Banking for payment centralizationArchiving (FS-PE-ARC) PUBLIC 333

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 S/4HANA Library on SAP Help Portal under http://help.sap.com/erp Cross-Application Functions Cross-Application Components

SAP Information Lifecycle Management.

19.2 Archiving Tools

Use

For archiving data in Payment Centralization and other functions, you use these tools:

● Archive Administration (transaction SARA).The Archive Administration is the major tool for archiving tasks in Payment Centralization. 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 336].

More Information

Archiving Payment Data [page 336]



http://help.sap.com/disclaimer?site=http%3A%2F%2Fhelp.sap.com%2Ferp

Archiving Logs and Documents [page 350]

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


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

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

19.3 Archiving Payment Data

Use

You can use this process to archive, delete, and display payment orders and recalls in Payment Centralization.

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 Centralization to your requirements.

Process

Archiving Payment Orders

Payment Centralization 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 339].● 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 348].

For more information, see Archiving Payment Orders [page 339] .

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

Displaying Payment Orders and Archived Data

You can view payment orders in the archiving application.

For more information, see Displaying Payment Orders [page 349].



19.3.1 Archiving Payment Orders

Use

The system analyzes payment data in Payment Centralization 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 221].

NoteThe system handles payment items and collectors as part of the referenced payment order.

For more information, see Collector [page 259].

Using archiving object /PE1/ORD2 (Payment Centralization: Order Analysis), the system can archive data listed in table /PE1/DB_ORDER (Payment Orders in Payment Centralization). 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 Centralization, 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 Centralization 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 Centralization 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 Centralization (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 Centralization (headers)

Archive only

/PE1/DB_ACCR_DET Detail table of accruals Archive only

/PE1/DB_PAYM_REM Payment remittances in Payment Centralization (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.

19.3.2 Archiving Recalls

Use

The system analyzes and archives recalls in Payment Centralization 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 61].

Using archiving object /PE1/RCL (Payment Centralization: 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 Centralization 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 Centralization 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.

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

You can call the report that uses this archiving object from the SAP Easy Access screen by choosing Payment Centralization Archiving Archiving, Deleting, and Displaying Payment Data Archiving Request Agents .

More Information

For more information about request agents, see Request Agent [page 78].

19.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 Centralization Archiving Archiving, Deleting, and Displaying Payment Data Archiving Collector Categories .

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

Procedure

1. On the Easy Access screen, choose Payment Centralization 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)

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



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


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



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


19.3.10 Deleting Payment Items

Context

You can delete payment items in the Payment Centralization when all associated payment orders have been archived.

For more information, see Archiving Payment Orders [page 339].

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

Procedure

1. On the SAP Easy Access screen, choose Payment Centralization 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.

19.3.11 Displaying Payment Orders

Use

You can display payment orders in the archiving application and you can display archived data in Payment Centralization.

Procedure

Displaying Payment Orders and Collectors in the Archiving Application

1. On the SAP Easy Access screen, choose Payment CentralizationCentralization 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 Centralization database by choosing Database or Database and Archive.


Displaying Archived Data in Payment Centralization

● 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 Centralization Payment Order ManagementEdit 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 286].

● To display archived payment collector data, including customer collectors, clearing collectors, and queues:


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

● For information about how to display data that is archived in the File Handler Database, see Display File Handler Database [page 211].

19.4 Archiving Logs and Documents

Use

You archive application logs, change documents, and service-level agreements (SLAs) in the Archive Development Kit (ADK) [page 336] 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 Centralization 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 351].

● Archive change documents (transaction /PE1/CHDOC_AR_ARCH)For more information, see Archiving Change Documents [page 351].

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.

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


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




20 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 Centralization 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: 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 Centralization. For more information, see Payment Order [page 47].

● Overview: Payment Items (transaction /PE1/PI_DISPLAY)Displays information about payment items submitted to or created in Payment Centralization including the technical status of the payment items. For more information, see Payment Item [page 52].

● Overview: Additional Information (transaction /PE1/RM_DISPLAY)Displays additional information about payment items, such as payment notes.

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

Product Assistance for SAP S/4HANA Banking for payment centralizationInformation System (FS-PE-IS) PUBLIC 353

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)

21 DataSources in SAP S/4HANA Banking for payment centralization

You can use the DataSources in Payment Centralization 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.

21.1 Master Data

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

Content Versions There are no content versions.

RemoteCube-Capable No

Delta-Capable No

Extraction from Archives No

Product Assistance for SAP S/4HANA Banking for payment centralizationDataSources in SAP S/4HANA Banking for payment centralization PUBLIC 355

http://help.sap.com/disclaimer?site=http%3A%2F%2Fhelp.sap.com%2Fpaymentengine

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

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




Delta-Capable No



DataSources in SAP S/4HANA Banking for payment centralization

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

21.2 Flow Data

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

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.

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


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

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


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

21.2.4 Payment Item Aggregated Data Extractor

0PE_PAYMITEM_RECONC_AGGR_TRAN

Use

This DataSource enables reconciliation between the account managment system and Payment Centralization 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



21.2.5 Payment Item Detailed Data Extractor

0PE_PAYMITEM_RECONC_DETL_TRAN

Use

This DataSource enables reconciliation between the account management system and Payment Centralization 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




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








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








21.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 Centralization through SAP NetWeaver Business Warehouse. Using this DataSource, you can load aggregated reconciliation data for payment items into the BI system.

Technical Data




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.



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

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

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

21.3 Texts

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

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

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



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

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

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

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

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

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

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

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

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

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

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


Important Disclaimers and Legal Information

Product Assistance for SAP S/4HANA Banking for payment centralizationImportant Disclaimers and Legal Information PUBLIC 391

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