High- Level Specification

Functional Overview

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

The purpose of this interface is to transmit outbound delivery data from SAP S/4HANA to external 3PL systems to support warehouse execution activities such as picking, packing, and goods issue processing.

Not all outbound deliveries are transmitted; only deliveries that meet specific business criteria are in scope. These criteria are defined through configuration and business rules, such as shipping point, delivery type, and 3PL assignment.

Outbound deliveries may be transmitted to the 3PL even if they are not yet ready for picking. In scenarios where batch determination has not been completed, the outbound delivery is sent with a shipment block indicator. This allows the 3PL to receive early visibility of the delivery while clearly indicating that the delivery is not yet released for picking activities.

Once batch assignment is completed in SAP S/4HANA, the shipment block is removed. A subsequent update of the outbound delivery is then transmitted to the 3PL, informing that the delivery is now released and can be processed for picking. This approach ensures alignment between SAP and the 3PL on delivery readiness while enabling early planning and coordination.

Scope and Objectives

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

Process Flow Diagram

Assumptions

N/A

Dependencies

For tracing the transmission in the monitoring table

The table defined in this development should be included in the configuration Dashboard for 3PLs.

3PL assignment and activation table

Security, Integrity and Controls

Standard authorizations apply as FIORI app Change outbound deliveries.

Configuration Requirements

N/A

Special Requirements

N/A

Design Rationale

APIs  to be consumed: 

• API_OUTBOUND_DELIVERY_SRV_0002 – Outbound Delivery (OData service)

• API_CUSTOMER_RETURNS_DELIVERY_SRV_0002 - Customer returns Deliveries (OData service)

Outbound 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.

Parameter table structure:

The following standard events are triggered whenever there are changes in Outbound Delivery as documented in Event References:

• Outbound delivery created
• Outbound delivery changed
• Outbound delivery deleted
• Outbound delivery block changed
• Outbound delivery picking status changed
• Outbound delivery packing status changed
• Outbound delivery GI status changed
• Outbound delivery Item Created
• Outbound delivery Item Changed
• Outbound delivery 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. 

API Use

The following information should be retrieved for the document (LIKP-VBELN) using the following services:

• API_OUTBOUND_DELIVERY_SRV_0002 : Retrieve Single Outbound Delivery Including All Outbound Delivery Items 

Example:

GET <host>/sap/opu/odata/sap/API_OUTBOUND_DELIVERY_SRV;v=2/A_OutbDeliveryHeader(DeliveryDocument='80000001')?$expand=to_DeliveryDocumentItem HTTP/1.1

• API_CUSTOMER_RETURNS_DELIVERY_SRV_0002: Retrieve a single customer returns delivery including all customer returns delivery items:

Example: 

GET <host>/sap/opu/odata/sap/API_CUSTOMER_RETURNS_DELIVERY_SRV;v=2/A_ReturnsDeliveryHeader(DeliveryDocument='84000001')?$expand=to_DeliveryDocumentItem HTTP/1.1

Data Structure

Fields from the standard API will be used.

Processing Logic

1) Relevance and activation checks

For each outbound delivery considered for transmission, the system evaluates whether the delivery is relevant for a 3PL interface based on configuration and business rules.

The following checks are performed sequentially:

Every time a new event is raised from a Delivery document, the event is consumed via business event consumption and a subsequence event should be published for transmission if the following criteria is met:

• • • Interface activation and 3PL assignment: The system checks the 3PL assignment table defined in with ORG_TYPE = VSTEL, ORG_VALUE=LIKP-VSTEL and DOC_TYPE="DELIVERY".

If an entry exists and the field INTERFACE_ACT = ‘X’, the delivery is considered relevant for transmission and the assigned 3PL is determined.
If no active entry is found, the delivery is considered not relevant for transmission and no further processing is performed.

• • • Delivery type and event validation

The custom table DELIVERIES_3PL is validated using: Shipping point (LIKP-VSTEL), Delivery type (LIKP-LFART), Event type. 

If a matching entry exists, the delivery is eligible for transmission and the API specified in the configuration entry is used to extract the outbound delivery data.
If no entry is found, the delivery is not transmitted.

2) Monitoring and traceability

If the delivery is successfully identified as relevant for transmission, an entry is created or updated in the outbound monitoring table to ensure traceability of the transmission to the 3PL. The monitoring table structure is defined in .

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, 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 and

Language Requirements

N/A

User Interface Requirements

DELIVERIES_3PL table should be included in the Configuration Dashboard  and should be visible by business users. 
 

Sequencing

N/A

Volumetrics

Average: 85 documents per day

Performance Consideration

N/A

Error Handling

Error handling should be don at AIF level, if there is an error sending the data to the 3PL, the interface should be retriggered.

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 outbound delivery transmission flow across ERP, 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