High- Level Specification

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

The purpose of this interface is to transmit inbound delivery data from SAP S/4HANA to external 3PL systems to support inbound warehouse execution activities such as goods receipt preparation and unloading. 

Only inbound deliveries that meet predefined business criteria are transmitted. The scope is controlled through configuration and business rules, such as plant, delivery type, and 3PL assignment, ensuring that only relevant inbound deliveries are sent to the appropriate 3PL

Inbound deliveries may be transmitted to the 3PL before they are ready for goods receipt execution. In such scenarios, the inbound delivery provides early visibility for planning purposes. Subsequent updates to the inbound delivery are transmitted to reflect changes in status or data, ensuring alignment between SAP and the 3PL.

For each relevant inbound delivery, SAP S/4HANA sends the delivery data to CPI, where it is validated, transformed, and routed to the assigned 3PL using the standard API_INBOUND_DELIVERY_SRV_0002 service.

Scope and Objectives

The interface covers all Inbound deliveries created or updated in S/4HANA that are relevant for transmission to 3PL systems.

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

The table defined in this development should be checked within this development

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

APIs  to be consumed: 

• API_INBOUND_DELIVERY_SRV_0002

Inbound deliveries will be relevant for transmission only for specific shipping points (the ones related to a 3PL), delivery types and at certain event. 

This criteria may change between 3PLs so a custom table is needed to save this parameters and should be checked by Event Mesh before publishing the event for consumption. This table (DELIVERIES_3PL) is described in the FS ERP-984 3PL Warehouse Interface - Outbound Delivery Interface to Cloud Integration Suite and will be part of ERP-845 - 3PL Configuration Application FS.

API Use

• API_INBOUND_DELIVERY_SRV_0002 will be consumed if the criteria described in the Processing logic section is met

The following information shall be retrieved from S/4HANA for the inbound delivery document using API_INBOUND_DELIVERY_SRV_0002:

Handling Unit information is included for inbound deliveries, as HUs are assigned at origin prior to shipment and must be communicated to the 3PL for receiving and putaway.

The event that triggers the interface should be included in the payload to the 3PL so they can easily identify the type of update to be done in the system (Creation, update, deletion, etc)

Data Structure

Fields from the standard API will be used + Event that triggered the interface

Processing Logic

1) Relevance and activation checks

For each inbound delivery considered for transmission to a 3PL, the system evaluates whether the document is relevant based on configuration and business rules. The following checks are performed sequentially:

• • • Interface activation and 3PL assignment: Interface is activated: The system checks the 3PL assignment table defined in ERP-845 - 3PL Configuration Application FS using:

      • ORG_TYPE = VSTEL

      • ORG_VALUE = LIKP-VSTEL

      • DOC_TYPE = DELIVERY

If a matching entry exists and INTERFACE_ACT = ‘X’, the assigned 3PL is determined and processing continues.
If no active entry is found, the inbound delivery is considered not relevant for transmission and processing ends.

• • • Delivery rule validation and API selection: the custom table DELIVERIES_3PL is validated using:

      • Shipping point (LIKP-VSTEL)

      • Delivery type (LIKP-LFART)

      • Event type

If a matching entry exists, the event is published for transmission and the API specified in the configuration entry is used to extract the inbound delivery data (via CPI).
If no entry is found, the delivery is not transmitted.

2)Monitoring and traceability

If the inbound delivery is identified as relevant for transmission, an entry is created or updated in the monitoring table to trace the transmission to the 3PL. The monitoring table structure is defined in ERP-865 - 3PL Warehouse interface - Inbound acknowledgements - System Interface FS in Progress .

DOC_TYPE=DELIVERY

DOC_ID= LIKP-VBELN

DATE_SENT = System date

TIME_SENT = System time

If an entry already exists for the same DOC_TYPE and DOC_ID, it must be updated with the current DATE_SENT and TIME_SENT to reflect the latest transmission.

Interface Alert & Monitoring

Monitoring will be handled by and

Language Requirements

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

User Interface Requirements

N/A
 

Sequencing

N/A

Volumetrics

Around 10 docs / DAY

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 inbound delivery 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 delivery 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 inbound delivery after correction. The chosen approach and responsibilities  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

The solution must be tested in conjunction with the developments listed in the Dependencies section. End-to-end validation will include the participation of the relevant 3PL partners to ensure the completeness of the inbound delivery transmission flow across S4 HANA, middleware, and target logistics platforms.

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