You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 28 Next »

Status

  Approved

Owner
Stakeholders
Jira Request ID

ERP-171 - Getting issue details... STATUS

Jira Development ID

ERP-958 - Getting issue details... STATUS

High- Level Specification

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

1Open the Fiori application to access the functionality
2Select 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. 

3Display 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,  …

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

 

5Execute 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 956.


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

All Custom Messages will be translated to the 4 core languages as per KDD-055-Multi-Language Support

Special Requirements

NA



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

 

The Selection Parameters will be same as those available in the Manage Payments App.Additionally a new custom button called "Recall" will be added to the UI , allowing users to recall the payment orders.

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 address of the subsidiary will be retrieved 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 FieldValue
Clearing AreaIHB EMEA NA (SYGLOB)
Payment Order Number(Blank)
Company CodeAll
Payment Scenario(s)(All / Not specified)
Processing StatusUnflagged
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 address of the subsidiary will be retrieved 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 CodeDescriptionType Of ErrorResolution
ERR002Clearing Area is missing / invalidValidation ErrorEnsure Clearing Area is provided and matches configured IHB clearing areas (same as “Manage Payments” selection screen logic). 
ERR003No payment orders found for the selection criteriaBusiness / Data ErrorAdjust selection criteria (Created On dates, Processing Status, Company Code, Payment Scenario) and re-run. Confirm expected orders exist in the IHB order data source. 
ERR004Payment Order not eligible for Recall due to current processing statusBusiness Rule ErrorValidate 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. 
ERR005Recall Reason not providedValidation ErrorEnforce Recall Reason as mandatory when user triggers Recall action; prompt user to select a reason before execution. 
ERR006Recall function failed (standard recall returned error)Technical / Integration ErrorLog the recall API/FM return message; verify configuration for recall functionality in APM/IHB and reprocess after correcting customizing or document state. 
ERR007Subsidiary notification cannot be triggered (subsidiary type not determined)Data / Configuration ErrorValidate the “subsidiary in S/4 or not” lookup using the existing custom table; maintain missing mapping and re-run the notification logic. 
ERR008Email notification failed because recipient email is missing in BPData Quality ErrorMaintain subsidiary email in BP “IHB notifications” email address; re-trigger notification (or provide fallback routing mailbox). 
ERR009Email notification failed (SMTP / send process error)Technical ErrorCheck SAPconnect/SCOT configuration and email queue; reprocess failed emails after resolving the outbound communication issue.
ERR010Header accounting document not found for reversalData / Processing ErrorRetrieve accounting reference from payment item info for the internal bank account company code; verify that header invoice registration document exists and is linked correctly. 
ERR011Subsidiary clearing document not found for reset/reversalData / Processing ErrorRetrieve subsidiary document reference from payment item info of the BP owning the internal bank account; verify relationship is available and consistent for reset clearing. 
ERR012Accounting reversal failed (FI document cannot be reversed)Technical / FI Validation ErrorReview FI reversal error (period status, authorization, document status, open item clearing state). Correct root cause (open period, permissions, etc.) and retry.
ERR013Original invoice update failed: blocking flag/category not removedData / Update ErrorEnsure 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. 
ERR016Background job execution failed / timeout due to volumePerformance / Runtime ErrorRun 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

Test Conditions and Expected Results



IDConditionExpected Result
1Execute 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
2Execute the program with selection criteria that return no dataSystem displays no payment orders and informs the user that no records were found
3Select one or more eligible payment orders and trigger the Recall functionSelected payment orders are successfully recalled and stopped before bank processing
4Attempt to trigger Recall without providing a Recall ReasonSystem blocks execution and prompts the user to enter a Recall Reason
5Recall a payment order with a valid Recall ReasonRecall reason is stored and associated with the recalled payment order
6Recall a payment order for a subsidiary that is not in S/4Email notification is sent to the subsidiary using the BP email maintained for IHB notifications
7Recall a payment order for a subsidiary that is in S/4System-driven notification is triggered according to the configured internal mechanism
8Recall a payment order when subsidiary email is not maintained in BPSystem raises an error and prevents notification from being sent
9Reverse a recalled payment order with existing header accounting documentHeader invoice accounting document is successfully reversed
10Reverse a recalled payment order with subsidiary clearing documentSubsidiary clearing document is reset or reversed successfully
11Execute reversal after recallOriginal invoice blocking flag for the factored program is removed
12Execute reversal after recallTrading Partner field is restored to its original value
13Attempt reversal when accounting period is closedSystem raises an FI validation error and reversal is not executed
14Execute steps Recall, Notification, and Reversal as a single processIf any step fails, none of the subsequent steps are executed, ensuring data consistency
15Run the program in background for high-volume processingProgram completes successfully within acceptable performance limits

Test Considerations/Dependencies

Business partners must be extended to the company codes.


Other Information


Development Details

Package

Package NameParent Package




Enhancement Implementation

Enhancement TypeStandard Definition NameCustom Implementation NameDesign Rationale Reference









Other Development Objects

Object TypeObject NamePurpose/High Level LogicDesign 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

ZFIZMMZPSZCOZSDZBCZFIZCA
TABLESZFITZMMTZPSTZCOTZSDTZBCTZFITZCAT

See also


No files shared here yet.

Change log

Version Published Changed By Comment
CURRENT (v. 28) May 04, 2026 09:20 TIRUKOTI-ext, Ramesh
v. 29 Apr 24, 2026 08:36 PERAL-ext, Carlos
v. 28 Apr 24, 2026 08:34 PERAL-ext, Carlos
v. 27 Apr 22, 2026 09:55 TORRES-ext, Benedict
v. 26 Apr 22, 2026 09:54 TORRES-ext, Benedict
v. 25 Apr 22, 2026 09:09 TIRUKOTI-ext, Ramesh
v. 24 Apr 22, 2026 09:08 TIRUKOTI-ext, Ramesh
v. 23 Apr 22, 2026 08:55 TORRES-ext, Benedict
v. 22 Apr 22, 2026 08:39 TIRUKOTI-ext, Ramesh
v. 21 Apr 21, 2026 15:06 TIRUKOTI-ext, Ramesh

Go to Page History

  • No labels