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

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

Follow program authorization checks

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

• 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 program

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

<Include an overview of the table and what it’s used for>

Configuration Table

NA

Include an overview of the table and what it’s used for

Selection Screen Enhancement

It should be replicated the selection screen of the Manage Payments fiori app :

Processing Logic

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

• 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

*

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
• Update the trading Partner to the original value

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 

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

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

Test Considerations/Dependencies

Business partners must be extended to the company codes.

Other Information

Development Details

Package

Enhancement Implementation

Other Development Objects

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.

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.

Change log