| Status | Revision under Review |
|---|---|
| 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 - 3PL Warehouse Interface - Outbound Delivery Interface to Cloud Integration Suite
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 events.
This criteria may change between 3PLs so custom configuration tables are needed to store these parameters and should be checked by Event Mesh before publishing the event for consumption. These tables (3PL Interface Activation and Assignment, and DELIVERIES_3PL) are defined in ERP-984 - 3PL Warehouse Interface - Outbound Delivery Interface to Cloud Integration Suite (see Configuration Requirements in that specification).
API Use
The API to be consumed for each delivery is determined by the configuration table DELIVERIES_3PL defined in ERP-984.
The following information shall be retrieved from S/4HANA for the inbound delivery document using API_INBOUND_DELIVERY_SRV_0002:
| Structure | Description |
|---|---|
A_InbDeliveryHeader | Delivery header |
A_InbDeliveryPartner | Header partners |
A_InbDeliveryAddress | Partner address detail (street, city, postal code, country) |
A_InbDeliveryHeaderText | Header texts |
A_InbDeliveryItem | Delivery items |
A_InbDeliveryItemText | Item texts |
A_HandlingUnitHeaderDelivery | Handling unit headers |
A_HandlingUnitItemDelivery | Handling unit items |
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 Interface Activation and Assignment table defined in ERP-984 with VSTEL = LIKP-VSTEL and 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 type and event validation: The configuration table DELIVERIES_3PL defined in ERP-984 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
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
Users should be able to display the configuration tables defined in ERP-984 through SAP Custom Business Configuration. Modification of table entries is restricted to the technical team via transport requests.
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 |
|---|---|---|---|