Dear Logistics Community,
after two exhausting but also interesting and valuable years of development for Advanced Shipping & Receiving (Adv. SR) I want to dedicate this blog post to a very special but very important topic:
What have we learned during the Adv. SR development regarding the system architecture of SAP R/3 and what have we improved in the context of the so called “Advanced Shipping Notification“?
But let me illustrate the topic step by step…
In the existing SAP R/3 world and with the “old” Shipping & Receiving functionality without SAP Transportation Management and SAP Extended Warehouse Management, there are a number of limitations that SAP customers have often only been able to overcome through extensive in-house development. One of the biggest problem areas was the object structure with the LE-TRA Shipment, which was used semantically differently on the supplier and customer side, as well as the corresponding EDI messages (in the form of IDOCs):
Figure 1: LE-TRA – Object and Message Structure
It is important to mention that this architecture has existed for a very long time and was sufficient at the time of its creation, but logistics and especially EDI communication has always evolved over the years. Therefore, customers were forced to build many of their own developments on the existing standard (and consulting solutions have been created on this basis as well). Looking at the object structure in SAP R/3 generally, it is immediately apparent that the shipment object was used as a consignment object on the supplier side, but as a bordero / load object on the customer side.
But why is the consignment object so important in general and why was the LE-TRA Shipment used as semantic Consignment on the supplier side (in SAP R/3)? This is relatively easy to explain if you take a look at the various message standards (such as EDIFACT).
Excerpt from the UN/EDIFACT message type “DESADV” (Advanced Shipping Notification):
“The message intent is to advise of the detailed contents of a consignment.”
The same applies to the UN/EDIFACT message type “IFTMIN”:
“The instruction results in a transport contract for a consignment and is primarily meant for administrative purposes. It will be the message from shipper to carrier or forwarder containing the final details of the consignment for which services are provided.”
If you look at the structural design of the “classic” EDI standards (such as DESADV / VDA4987) with this information, you quickly realize that not only the “Consignment” level was missing in the past, but there were also structural problems in the mapping between the Shipment and DESADV / VDA4987.
The following figure shows the rough message structure of the SHPMNT IDOC structure on the left, the VDA standard 4987 (same as Global DESADV) in the middle, and the structure of the TM web services on the right:
Figure 2: SHPMNT IDOC vs. EDIFACT / VDA vs. TM Web Service
The picture shows that the IDOC structure is not really oriented to the VDA standard and that the message contents, especially those relating to delivery and handling unit information, involve a huge mapping effort. The TM Web Services, on the other hand, are based on the EDIFACT standard, which simplifies mapping to the EDIFACT/ VDA messages.
However, as part of the Advanced Shipping & Receiving initiative, the existing architecture was reviewed by SAP in general and the existing weaknesses were to be eliminated. By the way, there is also an excellent blog post from Joerg Michaelis as well as a really nice podcast session with Peter Flensberg and Joerg Michaelis.
At the latest with the introduction of the consignment object in the backend, we were now “READY” for future logistics processes and could also better represent the Advanced Shipping Notification structurally through the web service TransportationOrderGenericRequest.
From a conceptual point of view, we are now able to send a generic web service from each object level (Freight Unit, Consignment, Freight Order), which contains a so-called business scope (e.g. ASN, Bordero, …) and can thus also be used semantically for specific use cases.
Figure 3: Principle of One Generic Interface
Furthermore, beside the already existing information we have extended the web service TransportationOrderGenericRequest with the fields that are mandatory in the message standard DESADV / VDA4987. These include, for example:
- (Un-)Loading Point
- (Goods) Supplier
- Batch Information (Date of Manufacture, Shelf Life Expiration Date, Country of Orign,…)
- Serial Numbers
- etc.
Even though the mappings are structurally simplified, there is also a certain effort to perform the mappings between EDI Standard and TM web service. For “new” mappings this should require little effort, but for the conversion of existing mappings this is of course somewhat more complex. Regardless of this, we wanted to support customers in doing the mapping in general, which is why we got active support from the project and market experienced colleagues of the SAP Premium Hub Center of Expertise (CoE), who reviewed the functionality on the one hand and on the other hand also worked out a mapping proposal, which we are now publishing in the form of a consulting note. This should generally make it easier to understand the fields of the TM Web Service TransportationOrderGenericRequest and to perform mappings to EDI standards. Even if features & functions are still missing to fulfil all customer requirements, we are now able to cover the current mandatory fields in the Global DESADV / VDA4987 with the TransportationOrderGenericRequest.
As already mentioned, this web service can also be used for other levels and business scopes (e.g. Bordero), so we have come a good step closer to our target vision. This then includes a clear object structure and communication on all levels, which is also graphically represented in the following figure:
Figure 4: Adv. SR – Object and Message Structure (Supplier / Customer / Carrier)
By the way, there are also some more cool (rather technical) features which were not available for IDOCs:
Action Code Handling (Create, Update, Delete)
IDOC contains a qualifier in the control segment to tell the recipient that a message is an original, a duplicate, an update or a deletion. SOA based messages uses field <ActionCode> for this purpose. The action codes “01” (Create), “02” (Change), “03” (Delete), and “06” (No Action) model strict semantics that lead to errors at the recipient if the object requested by the sender exist (“01”) or do not exist (“02”, “03”, “06”) at the recipient. Using strict semantics, therefore, requires that the sender has and uses information about the messages it has already sent. The ActionCodes “04” (Save) and “05” (Remove) model soft semantics that do not lead to errors if the respective elements do not exist at the recipient. Currently soft semantics has been applied in TransportationOrderGenericRequest messages, but it is also possible to switch to hard action codes for specific use cases.
B2B Communication
In B2B communication, master data is communicated based on external IDs and address information. Examples for external IDs, which are also called Standard IDs, are the Dun & Bradstreet number, Standard Carrier Alpha Code (SCAC), Global Location Number (GLN), etc. In TM, the respective Standard IDs can be maintained in related master data for business partner, location and product.
Delta Handling
An important feature of the service interface is to support delta messages. In the past, only full updates were possible which means that all data needs to be sent. Missing data is interpreted as to be deleted. According to the concepts of Modular TM the sending system might only contain a subset of the documents. Thus, a full update would not be possible for the sender of the message and the receiver would remove the missing document from the addressed document which would be wrong, though.
Message Sequencing
In asynchronous communications it is important that the messages are processed by the receiver in the right sequence. For full messages it is possible that a newer message can be processed before an older one. The older one will be discarded when it arrives at a later point in time. Delta messages need to be processed strictly in the order in which the messages are sent, and no message must be skipped.
Service Groups
A service group is a mechanism to determine receivers (Web service providers). This is either based on logical or technical routing and configuration is possible for either one or multiple receivers:
- Logical receiver determination (LRD) is based on the business context that is provided using an LRD filter. During configuration, routing rules are defined. It allows flexible routing of web service calls. At runtime, the consumer application passes the business context to route the calls to the correct provider application.
- Technical receiver determination (TRD) determines the receivers based on technical IDs. It is used by the Web service consumer application if the application knows which receiver to address.
Error Tolerant Inbound Processing
This is perfectly outlined in an episode of the TM podcast, therefore nothing to explain specifically in this blog post.
Finally, here are some additional remarks:
- The web service for ASN (TransportationOrderGenericRequest) is following all SOAP specifics
- Technically, PPF is used to trigger the ASN (standard scheduling condition is goods issue posting of the entire Consignment)
- We will further improve the EDI communication in the upcoming releases
I hope you enjoyed reading this. Looking forward to your comments!
Source: https://blogs.sap.com/2022/08/22/sap-advanced-shipping-receiving-advanced-shipping-notification-on-consignment-level/
Configure follow-up action
