| Status | |
|---|---|
| Owner | |
| Stakeholders | |
| Jira Request ID | |
| Jira Development ID |
High- Level Specification
| Parameter | Value |
|---|---|
| Application System | S/4Hana ROW, S/4Hana CUI |
| Business Process Reference | 09.06.02.04. Manage Centralized Outgoing Payments on Behalf of Subsidiaries 09.06.02.05. Manage Centralized Incoming Payments on Behalf of Subsidiaries |
Functional Overview
This program will support the automation of the reversal of the payment orders ( IHB contracts ) based on standard features.
Scope and Objectives
The project involves the implementation of a factoring solution within In-House Bank (IHB) using the S/4 Hana FI/IHB module. This system is designed to handle transfer of AP/AR items that are relevant for factoring, to the IHB center for further collection/payable management.
This enhancement covers the reversal of them in case is needed.
Process Flow Diagram
09.06.02.04. Manage Centralized Outgoing Payments on Behalf of Subsidiaries
09.06.02.05. Manage Centralized Incoming Payments on Behalf of Subsidiaries
Step | Description | Comment |
|---|---|---|
| 1 | Open the Fiori application to access the functionality | |
| 2 | Select the parameters from the selection screen | The report should have a selection screen with the following fields .All fields they need to be able to select single value, a range of information or multiple values. |
| 3 | Display the output of the selected payment orders | The Output of the report should be Fiori with similar to ALV features like to add / remove fields , sort , sum/semisum, sort, filter, … |
| 4 | Select invoices for Reversal | When I display the information, I should be able to select and deselect the relevant invoices for Factoring (selection flag with multiple selection or all should be available and a button to execute the action).
|
| 5 | Execute reversal |
|
Assumptions
Its expected to reverse the same amount that has been factored and the header document generated .
Dependencies
Finance Invoice settings
APM / In House Bank Settings including recall functionality
Enhancements relating to performing factoring of the open invoices (AP/AR) from affiliate to IHB from 953 to 959 and 963
Security, Integrity and Controls
In case of 09.06.02.03. Manage End of Day Processing for In House Bank the authorization is only based on access to the functionality for In-house Bank Payment Processor role .
Configuration Requirements
Finance Invoice settings
APM / In House Bank Settings including recall functionality
Language Requirements
No specific language requirement
Special Requirements
NA
If the enhancement interacts with third-party systems such as Icertis, describe any additional integration, security or authentication considerations that must be taken into account.
Design Rationale
Functional Requirements
A custom program will be created for reverse the payment orders received from the subsidiaries or manually created. These are the following scenarios that will be covered:
▪ Items for Release: Payment transactions that are awaiting user authorization or release
▪ Items Received: Lists payments that have been received into the system but have not yet entered further processing.
▪ Items in Repair: Payments that contain errors or require correction before they can be processed further.
▪ Blocked Items: Payments that have been automatically or manually blocked
It will be created a Fiori app to access by business to it but also a program to be executed / used by other programs in case of specific events.
Selection Screen
In the selection screen the following fields should appear:
- Clearing Area
- Payment Order Number
- Company Code
- Payment Scenario
- Processing Status
- Created On
- Created By
- Direction
- …
Like in the Manage Payments One but adding the recall reason.
Once the selection is done the program use the recall function the Recall function is to stop the payment before it is sent out to the bank bringing the recall reason selected
Notifications to subsidiaries
When a Payment Order is recalled, a system driven notification mechanism should be implemented. The proposed solution is to trigger an automated notification depending on if the subsidiary is in S/4 or not (reuse existing custom table of
ERP-953 IHB Factoring-Business Partner enhancement) :
- email in case the subsidiary is not in S/4 : The email from the subsidiary will be retrieve from the BP email information linked to IHB notifications.
Subject: Payment Rejection Notification
Dear [Subsidiary Name],
We regret to inform you that your recent payment attempt of [amount] on [date] has been unsuccessful and was rejected by our system.
Reason for Rejection:
[Insert reason here from the recall reason added in the recall process*.]
Please review the details and take the necessary steps to resolve the issue:
- Verify payment details.
- If you need assistance, contact our support team at [phone/email].
Once the issue is resolved, you may retry the payment.
We apologize for any inconvenience this may have caused and appreciate your prompt attention to this matter.
Thank you.
Payment details:
- Document Number
- Fiscal Year
- Document Date
- Posting Date
- Document Type
- Reference Document
- Customer / Vendor
- Header Text
- Sales Order
- SD Billing
- Payment Ref
- Reference Key 1
- Reference Key 2
- Reference Key 3
Whenever a Payment Order is cancelled or reversed in SAP. This notification will inform the subsidiary that the payment will not be executed and must be reinitiated if still required.
After this or in parallel it should be removed the accounting entries generated for :
- Header invoice registration ( and clearing if applied ) . This information will be retrieved from the payment item information of the company code that owns the internal bank account:
- Document Number (BELNR): Unique identifier for the accounting document
- Fiscal Year (GJAHR): Fiscal year of the document posting
- Document Date (BLDAT): Date on the document
- Subsidiary clearing document ( and clearing process if applies ) . This information will be retrieved from the payment item information of the BP that owns the internal bank account:
- Document Number (BELNR): Unique identifier for the accounting document
- Fiscal Year (GJAHR): Fiscal year of the document posting
- Document Date (BLDAT): Date on the document
- Update the original invoice removing the flag of blocking with specific category for reversed Factored program
- Update the trading Partner to the original value
Proposed Technology to Use
Custom FIORI app .
Data Source Considerations
IHB Contract : /PF1/DB_ORDER ( from Clearing area onwards from the previous list )
Data Validation Considerations
NA
Custom Tables
N/A
Master Data
NA
Configuration Table
NA
Selection Screen Enhancement
It should be replicated the selection screen of the Manage Payments fiori app :
Processing Logic
Step 1 Selection Screen Fields / parameters
Populate the fields available in the selection screen:
| Screen Field | Value |
|---|---|
| Clearing Area | IHB EMEA NA (SYGLOB) |
| Payment Order Number | (Blank) |
| Company Code | All |
| Payment Scenario(s) | (All / Not specified) |
| Processing Status | Unflagged |
| Created On (From) | First day of the month |
| Created On (To) | Last day of the month |
| Created By | (Blank) |
| Direction | (All) |
Step 2 : Output of the report
Once the selection is done the program the output should be similar to the logic of the Manage Payments fiori app.
Use CDS views /PF1/CV_ORDER_MANAGE and /PF1/C_ITEM_ORDER_MANAGE to get the Payment Order Details.
Step 3 : Recall Function
Select the payment order or payment order and press the Recall function . Use Method RECALL from class /PF1/CL_PO_GUI_OPERATIONS. Pass PaymentOrderGuid and Recall Reason.
Step 4 : Recall Reason
This will stop the payment before it is sent out to the bank bringing the recall reason selected
After this the recall has happened.
Step 5 : Notifications to subsidiaries
When a Payment Order is recalled, a system driven notification mechanism should be implemented:
The proposed solution is to trigger an automated notification depending on if the subsidiary is in S/4 or not (reuse existing custom table) :
- email in case the subsidiary is not in S/4 : The email from the subsidiary will be retrieve from the BP email information linked to IHB notifications.
Subject: Payment Rejection Notification
Dear [Subsidiary Name],
We regret to inform you that your recent payment attempt of [amount] on [date] has been unsuccessful and was rejected by our system.
Reason for Rejection:
[Insert reason here from the recall reason added in the recall process*.]
Please review the details and take the necessary steps to resolve the issue:
- Verify payment details.
- If you need assistance, contact our support team at [phone/email].
Once the issue is resolved, you may retry the payment.
We apologize for any inconvenience this may have caused and appreciate your prompt attention to this matter.
Thank you.
Payment details:
- Document Number (BELNR): Unique identifier for the accounting document
- Fiscal Year (GJAHR): Fiscal year of the document posting
- Document Date (BLDAT): Date on the document
- Posting Date (BUDAT): Date when the document was posted to SAP
- Document Type (BLART): Type of accounting document (invoice, payment, etc.)
- Reference Document (XBLNR): External reference number
- Customer ( KUNNR ) / Vendor (LIFNR ) : Customer / Vendor account number.
- Header Text (BKTXT): Descriptive text for the document header
- Sales Order (KDAUF): Sales order reference
- SD Billing ( AWEKEY ): SD Billing Document
- Payment Ref ( KIDNO ) : Payment Reference
- Reference Key (XREF1 ) : Relevance information in text field
- Reference Key (XREF2 ) : Relevance information in text field
- Reference Key (XREF1 ) : Relevance information in text field
*
Step 6 : Reverse the invoices from header and subsidiaries
Whenever a Payment Order is cancelled or reversed in SAP. This notification will inform the subsidiary that the payment will not be executed and must be reinitiated if still required.
After this or in parallel it should be removed the accounting entries generated for :
- Header invoice registration ( and clearing if applied ) . This information will be retrieved from the payment item information of the company code that owes the internal bank account:
- Document Number (BELNR): Unique identifier for the accounting document
- Fiscal Year (GJAHR): Fiscal year of the document posting
- Document Date (BLDAT): Date on the document
- Subsidiary clearing document ( and reset clearing if applies ) . This information will be retrieved from the payment item information of the BP that owns the internal bank account:
- Document Number (BELNR): Unique identifier for the accounting document
- Fiscal Year (GJAHR): Fiscal year of the document posting
- Document Date (BLDAT): Date on the document
- Update the original invoice removing the flag of blocking with specific category for reversed Factored program(BSEG-
ZLSPR) - Update the trading Partner to the original value(BSEG-VBUND)
From the header invoice registration I can get the subsidiary document . And the subsidiary document I can get from the REFERENCE DOC _DOC in the subsidiary:
/PF1/DB_ORDER Field ACDOCA Field
MANDTR CLNT Client matching
COMPANY_CODER BUKRS Company code alignment
REFERENCE_DOC BELNR Document reference
ORDER_ID AWREF Reconciliation key mapping
It is critical that if the execution of any of steps 4, 5, or 6 fails, none of these steps are executed, in order to avoid inconsistencies. If someone fails no one should be executed in real.
Use RAP BO I_JOURNALENTRYTP to Reverse the Header Invoice and the clearing document on Subsidiary
Provide a Custom action to process Recall Payment orders in background in case if the volume is high.
Volumetrics
This volume is estimated to be approx: 10000
Performance Considerations
Enhancement must be run using a job in background or event based on BP creation/modification
Error Handling
| Error Code | Description | Type Of Error | Resolution |
|---|---|---|---|
| ERR002 | Clearing Area is missing / invalid | Validation Error | Ensure Clearing Area is provided and matches configured IHB clearing areas (same as “Manage Payments” selection screen logic). |
| ERR003 | No payment orders found for the selection criteria | Business / Data Error | Adjust selection criteria (Created On dates, Processing Status, Company Code, Payment Scenario) and re-run. Confirm expected orders exist in the IHB order data source. |
| ERR004 | Payment Order not eligible for Recall due to current processing status | Business Rule Error | Validate status against the supported buckets (e.g., items for release/received/in repair/blocked) and only allow recall when permitted by the standard recall capability. |
| ERR005 | Recall Reason not provided | Validation Error | Enforce Recall Reason as mandatory when user triggers Recall action; prompt user to select a reason before execution. |
| ERR006 | Recall function failed (standard recall returned error) | Technical / Integration Error | Log the recall API/FM return message; verify configuration for recall functionality in APM/IHB and reprocess after correcting customizing or document state. |
| ERR007 | Subsidiary notification cannot be triggered (subsidiary type not determined) | Data / Configuration Error | Validate the “subsidiary in S/4 or not” lookup using the existing custom table; maintain missing mapping and re-run the notification logic. |
| ERR008 | Email notification failed because recipient email is missing in BP | Data Quality Error | Maintain subsidiary email in BP “IHB notifications” email address; re-trigger notification (or provide fallback routing mailbox). |
| ERR009 | Email notification failed (SMTP / send process error) | Technical Error | Check SAPconnect/SCOT configuration and email queue; reprocess failed emails after resolving the outbound communication issue. |
| ERR010 | Header accounting document not found for reversal | Data / Processing Error | Retrieve accounting reference from payment item info for the internal bank account company code; verify that header invoice registration document exists and is linked correctly. |
| ERR011 | Subsidiary clearing document not found for reset/reversal | Data / Processing Error | Retrieve subsidiary document reference from payment item info of the BP owning the internal bank account; verify relationship is available and consistent for reset clearing. |
| ERR012 | Accounting reversal failed (FI document cannot be reversed) | Technical / FI Validation Error | Review FI reversal error (period status, authorization, document status, open item clearing state). Correct root cause (open period, permissions, etc.) and retry. |
| ERR013 | Original invoice update failed: blocking flag/category not removed | Data / Update Error | Ensure the program can identify the original invoice and update the “flag of blocking with specific category for reversed factored program”; confirm update authorization and field status. |
| ERR016 | Background job execution failed / timeout due to volume | Performance / Runtime Error | Run in background as designed; apply selection restrictions (date ranges), consider batching, and optimize reads/joins to support the ~10,000 volume estimate. |
Testing
How to Test
Please provide some guidance and/or test data to help the developer unit test the enhancement. Please include both positive and negative testing (to validate error situations handling). The developer will need to test repeatedly, so where appropriate provide instructions to reverse the actions performed so the test may be run again or explain how to create new input data to the test. The developer will need logons for test users representing the various roles within the approval process.
Test Conditions and Expected Results
| ID | Condition | Expected Result |
|---|---|---|
| 1 | Execute the program with valid selection screen parameters (Clearing Area, Company Code, Created On dates) | Payment orders matching the selection criteria are displayed in the output list |
| 2 | Execute the program with selection criteria that return no data | System displays no payment orders and informs the user that no records were found |
| 3 | Select one or more eligible payment orders and trigger the Recall function | Selected payment orders are successfully recalled and stopped before bank processing |
| 4 | Attempt to trigger Recall without providing a Recall Reason | System blocks execution and prompts the user to enter a Recall Reason |
| 5 | Recall a payment order with a valid Recall Reason | Recall reason is stored and associated with the recalled payment order |
| 6 | Recall a payment order for a subsidiary that is not in S/4 | Email notification is sent to the subsidiary using the BP email maintained for IHB notifications |
| 7 | Recall a payment order for a subsidiary that is in S/4 | System-driven notification is triggered according to the configured internal mechanism |
| 8 | Recall a payment order when subsidiary email is not maintained in BP | System raises an error and prevents notification from being sent |
| 9 | Reverse a recalled payment order with existing header accounting document | Header invoice accounting document is successfully reversed |
| 10 | Reverse a recalled payment order with subsidiary clearing document | Subsidiary clearing document is reset or reversed successfully |
| 11 | Execute reversal after recall | Original invoice blocking flag for the factored program is removed |
| 12 | Execute reversal after recall | Trading Partner field is restored to its original value |
| 13 | Attempt reversal when accounting period is closed | System raises an FI validation error and reversal is not executed |
| 14 | Execute steps Recall, Notification, and Reversal as a single process | If any step fails, none of the subsequent steps are executed, ensuring data consistency |
| 15 | Run the program in background for high-volume processing | Program completes successfully within acceptable performance limits |
Test Considerations/Dependencies
Business partners must be extended to the company codes.
Other Information
Development Details
Package
| Package Name | Parent Package |
|---|---|
Enhancement Implementation
| Enhancement Type | Standard Definition Name | Custom Implementation Name | Design Rationale Reference |
|---|---|---|---|
Other Development Objects
| Object Type | Object Name | Purpose/High Level Logic | Design Rationale Reference |
|---|---|---|---|
Appendix
Custom Authorization Group Naming Convention
This table is based on the Syensqo development standards document. It provides the naming conventions for authorization groups to associated with custom reports and tables to comply with security requirements.
ABAP | ZFI | ZMM | ZPS | ZCO | ZSD | ZBC | ZFI | ZCA |
|---|---|---|---|---|---|---|---|---|
| TABLES | ZFIT | ZMMT | ZPST | ZCOT | ZSDT | ZBCT | ZFIT | ZCAT |
See also
Insert links and references to other documents which are relevant when trying to understand this decision and its implications. Other decisions are often impacted, so it's good to list them here with links. Attachments are also possible but dangerous as they are static documents and not updated by their authors.
