| Status | Approved |
|---|---|
| Owner | RUIZ SOMOZA-ext, Carolina |
| Stakeholders | |
| Jira Request ID | ERP-545 - Getting issue details... STATUS |
| Jira Development ID | ERP-982 - Getting issue details... STATUS |
High- Level Specification
| Implementing System | S/4HANA |
|---|---|
| Invoked by/Invokes | ERP-983 - Getting issue details... STATUS |
| Business Process Reference | 06.10.01.01. Manage 3PL Warehouse Interfaces |
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
1 | Delivery created/updated in S/4HANA | |
2 | S/4 raises an internal event. | |
3 | System checks the 3PL assignment table | To determine if the interface is active and retrieve the 3PL assigned |
4 | System checks the DELIVERIES_3PL table | To determine if the delivery type, shipping point and event is relevant for transmission |
5 | Relevant event is published to SAP Event Mesh | If previous steps are successful |
6 | CPI consumes the event and retrieves full delivery using API | CPI will also get the 3PL partner from the 3PL assignment table for routing purposes |
7 | S/4 updates Monitoring Table | Using System date and time |
8 | 3PL consumes and executes warehouse processes. |
Assumptions
N/A
Dependencies
ERP-984 - Getting issue details... STATUS The table defined in this development should be checked within this development
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
API Use
API_INBOUND_DELIVERY_SRV_0002 will be consumed if the criteria described in the Processing logic section is met
The following information should be retrieved for the document (LIKP-VBELN) using the following services:
Retrieve Single Inbound Delivery Including All Inbound Delivery Items
Example
GET <host>/sap/opu/odata/sap/API_INBOUND_DELIVERY_SRV;v=2/A_InbDeliveryHeader(DeliveryDocument='180000247')?$expand=to_DeliveryDocumentItem HTTP/1.1Data Structure
Fields from the standard API will be used.
| Parent | Field | Description | Mandatory (Y/N) | Data Type |
|---|---|---|---|---|
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
ORG_TYPE =
VSTELORG_VALUE =
LIKP-VSTELDOC_TYPE =
DELIVERY
- Interface activation and 3PL assignment: Interface is activated: The system checks the 3PL assignment table defined in
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
- Delivery rule validation and API selection: the custom table DELIVERIES_3PL is validated using:
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
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 ERP-865 - Getting issue details... STATUS and ERP-844 - Getting issue details... STATUS
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
Test Conditions and Expected Results
| ID | Condition | Expected Results |
|---|---|---|
| 1 | Create an inbound delivery for a relevant delivery type and with a matching configuration entry in DELIVERIES_3PL (Event = CREATE) and interface activated in ERP-845 | Event is published for transmission. CPI consumes the event and extracts data using the API defined in the custom table entry. Monitoring entry is created/updated (DOC_TYPE/DOC_ID/DATE_SENT/TIME_SENT). |
| 2 | Update an existing relevant inbound delivery (Event = CHANGE) with matching DELIVERIES_3PL configuration | Update event is published and processed according to the configuration. Monitoring entry is updated with latest DATE_SENT/TIME_SENT. |
| 3 | Delete / cancel an inbound delivery (or execute the business scenario equivalent) | Deletion/cancellation notification event is published and consumed as designed; 3PL receives the update accordingly. |
| 4 | Create/update an inbound delivery that is not configured in DELIVERIES_3PL (no matching VSTEL + LFART + Event rule) | Event is not published (delivery not transmitted). |
| 5 | Create/update an inbound delivery for a non-relevant organizational criteria (e.g., shipping point not assigned / interface not activated in ERP-845) | Event is not published (delivery treated as not relevant). |
| 6 | Create inbound delivery relevant by rule, but set ERP-845 INTERFACE_ACT ≠ X for that org value | Event is not published due to inactive interface. |
| 7 | Transmission failure in CPI (simulate routing/mapping/endpoint error) for a relevant inbound delivery | Message shows failure in CPI/AIF monitoring. After correction, retrigger/reprocess results in successful transmission; monitoring timestamps updated. |
| 8 | 3PL returns ACK for a successful inbound delivery transmission | Transmission marked as successful in monitoring/ACK table per ERP-865 design |
| 9 | 3PL rejects / does not ACK | Error/pending status visible per monitoring design; retransmission after correction results in ACK and successful completion |
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
| Package Name | Parent Package |
|---|---|
Other Development Objects
| Object Type | Object Name | Purpose/High Level Logic | Design Rationale Reference |
|---|---|---|---|