High- Level Specification

Functional Overview

This Functional Specification describes the outbound Reservation interface between SAP S/4HANA and Third-Party Logistics providers (3PLs), implemented via SAP Integration Suite (CPI) using the standard OData service API_RESERVATION_DOCUMENT.

The purpose of this interface is to transmit reservation information created in SAP S/4HANA to the 3PL systems in order to provide visibility of planned or pre-allocated inventory movements. Reservations are used in SAP to reserve stock for specific processes or requirements before the corresponding physical movement is executed.

In scenarios where inventory is physically managed by a 3PL, the reservation information must be shared to allow the 3PL to prepare, plan, or restrict stock usage accordingly. This ensures alignment between SAP stock reservations and the inventory handling activities performed in the 3PL warehouse.

Only relevant reservations are transmitted. The scope of the interface is controlled through configuration and business rules, such as plant ensuring that only reservations that require action or visibility at the 3PL are sent.

For each relevant reservation created or updated in SAP S/4HANA, the reservation data is extracted and sent to CPI using the standard API_RESERVATION_DOCUMENT service. CPI validates, transforms, and routes the message to the assigned 3PL system

Scope and Objectives

This interface covers the transmission of Reservation documents created in S/4 HANA to the 3PLs (via CPI).

Process Flow Diagram

Assumptions

N/A

Dependencies

ERP-865 - 3PL Warehouse interface - Inbound acknowledgements - System Interface FS in Progress For tracing the transmission in the monitoring table

ERP-845 - 3PL Configuration Application FS in Progress 3PL assignment and activation table

Security, Integrity and Controls

Outbound interface triggered by a standard SAP event. The process that triggers the interface will take care of access control.

Configuration Requirements

N/A

Special Requirements

N/A

Design Rationale

API Use

• APIs  to be consumed: 

API_RESERVATION_DOCUMENT - (OData service) Retrieve Reservation Document 

Retrieve Items with Header using RKPF-RSNUM (Reservation number) and RESB table for items

Example

GET <host>/sap/opu/odata4/sap/api_reservation_document/srvd_a2x/sap/apireservationdocument/0001/ReservationDocument('{{Reservation}}')/_ReservationDocumentItem

• Reservation documents will be relevant for transmission only for specific plants and plant/storage location combinations (defined by 3PL). This criteria may change between 3PLs so a custom table is needed to save these parameters and should be checked before publishing the event for consumption.

Parameter table structure: RESERV_3PL

User Interface Requirements RESERV_3PL table should be included in the Configuration Dashboard ERP-845 -  and should be visible by business users.

The LGORT field should be exposed as an optional input. When left blank, the entry is interpreted as applying to all storage locations for the given plant, and should be displayed as "All storage locations" to avoid ambiguity for business users.

The following standard events are triggered whenever there are changes in Reservation document as documented:

• Created 

• changed
• Deleted
• Item created
• Item changed
• Item deleted

Since derived events and metadata extension is either not possible or not useful for the requirement, the following events will be consumed in S/4HANA through Business Event Consumption with the custom filter logic and a custom event will be published to Event Mesh with additional information. 

The event triggering the interface should be included in the data sent to the 3PL. 

The event triggering the interface should be included in the data sent to the 3PL. The event is included at header level. If the event is triggered by an item-level change, the event is also included at item level for the affected item.

Processing Logic

1) Relevance and activation checks

Every time a new event is raised from a Reservation document, the system evaluates whether the document is relevant for outbound transmission to a 3PL based on the configuration table RESERV_3PL.

The following two-step lookup is performed:

Step 1 — Specific lookup (plant + storage location):

The table RESERV_3PL is evaluated using:

• Plant (RESB-WERKS)
• Storage Location (RESB-LGORT)

If a matching entry is found, the reservation is considered relevant for outbound transmission and the 3PL is determined from the 3PL_ID field of the matching entry.

Step 2 — Fallback lookup (plant only):

If no entry is found in Step 1, the system performs a second lookup using:

• Plant (RESB-WERKS)
• Storage Location = blank

If a matching entry is found, the reservation is considered relevant for outbound transmission and the 3PL is determined from the 3PL_ID field of the matching entry.

If neither lookup returns a result, the reservation is considered not relevant for transmission and no further processing is performed.

2) Monitoring

If the reservation is identified as relevant for outbound transmission, an entry is logged in the monitoring table to trace the transmission to the 3PL. The monitoring table structure is defined in ERP-865 

DOC_TYPE=RESERVATION

DOC_ID= RKPF-RSNUM

DATE_SENT = System date

TIME_SENT = System time

If an entry already exists for the same document, the record is updated with the current DATE_SENT and TIME_SENT to reflect the latest transmission.

Interface Alert & Monitoring

Monitoring will be handled by ERP-865 - 3PL Warehouse interface - Inbound acknowledgements - System Interface FS in Progress and ERP-844 - 3PL Warehouse Interface - Monitoring dashboard FS in Progress

Language Requirements

Document texts will be in the language of the source document.

User Interface Requirements

N/A 

Sequencing

N/A

Volumetrics

Around 5 docs per day for all 3PLS

Performance Consideration

N/A

Error Handling

Error handling is managed through SAP Application Interface Framework (AIF) and SAP Integration Suite (CPI) to ensure reliable transmission of reservation data to the 3PL.

If an error occurs during data extraction or transmission to CPI or the 3PL, the interface execution is marked as failed and the error is visible in AIF and/or CPI monitoring. The interface must support retriggering.

Configuration or relevance errors result in the reservation being treated as not relevant for transmission and no message being sent.

Retransmission requirement (dependency):
Where the 3PL rejects a message due to functional reasons on the 3PL side (e.g. missing/invalid master data), a controlled mechanism must exist to retransmit the document after correction. The chosen approach must be confirmed with the technical team.

Testing

How to Test

Please provide some guidance and/or test data to help the developer unit test the interface. 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. In particular, the developer will need logons for test users representing the various roles within the approval process.

Test Conditions and Expected Results

Test Considerations/Dependencies

List any considerations essential for application test planning (e.g., test this before ABC along with DEF separate from GHI). If the development encompasses a user interface, explain how to test it. List any insights as to how this component could be tested the most efficiently.

Other Information

Development Details

Package

Other Development Objects

Appendix

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