Shipment Data Transfer from ECC to TM Without Middleware
There are multiple ways to send data from one SAP system to another for several scenarios. IDocs and webservices can fulfil most of your integration requirements. However, there maybe times when your project requires you to achieve something that is not standard SAP behaviour. And when SAP does not provide such functionalities, you must figure out a workaround.
One of those scenarios is Shipment Transfer from ECC system to TM system without a middleware.
SAP does not allow point-to-point connection for data transfer from Shipment in ECC to Freight Order in TM system. It mandates the use of PI system as a middleware. This means that once you have triggered Shipment creation from a Freight Order in TM, you do not have the confirmation from ERP system if PI system is not involved. Furthermore, any change of Shipment Status is also not sent back to TM system. Hence, the Freight Order Status remains unchanged.
In this blogpost, I have shared the solution to send shipment data from ECC system to TM system. The data includes both confirmation details as well as status change details. We will be building an RFC that will be called by the ECC system and will update the corresponding Freight Order in TM system. If required, similar solution can be used for numerous Freight Order fields with the right bit of BOPF coding.
Attached below are the screenshots of the Freight Order fields I will update based on Shipment Data
• Basic understanding of BO structure
• Knowledge of BOPF coding
• Understanding of BO node actions
The fields to be updated are:
2. Transmission-to-ERP status
3. Last ERP Confirmation On/At
4. Lifecyle Status
5. Execution Status
6. Logistical Execution Status
And this is the mapping between the ECC shipment fields and the corresponding status in FO in TM. When the Shipment Status fields are checked (‘X’), the corresponding status code should be updated in FO in TM system.
|Shipment Status Field (X)||Execution Status (SAP TM)||Lifecycle Status (SAP TM)||Logistical Execution Status (TM system)|
|VTTK-STLBG||Loading In Process (09)||In Process (02)|
|VTTK-STLAD||Ready for Transportation Execution (07)||In Process (02)||Loaded (18)|
|VTTK-STTBG||In Execution (03)||In Process (02)|
|VTTK-STTEN||Executed (04)||In Process (02)|
|VTTK-STABF||Executed (04)||Completed (05)|
Step 1: Build RFC Function Module in TM system
First, we will build the RFC (Remote Function Call) which will be called from ECC. The RFC will be developed in TM system and will be called when the Shipment is created, updated, or deleted. Identify the nodes in which the above fields are present.
Of the above TM fields, all, except the Logistical Execution Status field, are present in the Root Node. Therefore, the actions to update the fields will be present under the Root Node. The Actions are:
- ASSIGN_TSP (To Update carrier)
- SET_EXM_STATUS_EXECUTED (Set Execution status to Executed)
- SET_LC_COMPLETE (Set lifecycle status to Processed)
- SET_LC_IN_PROCESS (Set lifecycle status in Process)
- SET_EXM_STATUS_READY_FOR_EXEC (Set Execution Status to Ready for Execution)
- SET_EXM_STATUS_IN_LOADING (Set Execution Status to in Loading)
- SET_EXM_STATUS_IN_EXECUTION (Set Execution Status to In Execution)
The Logistical Execution Status field is present under STOP Node and the action to change its status to ‘Loaded’ is SET_HANDLING_EXECUTION.
The fields Transmission-to-ERP status and Last ERP Confirmation On/At are updated by MODIFY method of Interface /BOBF/IF_TRA_SERVICE_MANAGER.
The above Actions are executed using the method DO_ACTION of interface /BOBF/IF_TRA_SERVICE_MANAGER.
Let us come to RFC now and see the logic that has been implemented.
- In our system, we have kept the Freight Order and Shipment number range same. Therefore, the freight order number (TOR) is same as the shipment number.
- Get the TOR ID in a variable. Pass it through a Conversion routine before assigning it to the internal table of type /SCMTMS/T_LOC_ALT_ID.
- We will use the TOR ID as an Alternate Key to retrieve the Root details.
- We also need to instantiate the Service Manager and Transaction Manager.
- Now we retrieve the TOR GUID from the Freight Order Number and use it to fetch Root Details.
- Now we pass the Transmission status and ERP Confirmation Date/Time and create the parameters for MODIFY Method.
- Pass the parameters to MODIFY method and SAVE the changes by calling the Transaction Manager.
- Now we update the Carrier in the TOR structure. The challenge here is to populate the Action Parameters Declare an object of type /SCMTMS/S_TOR_ROOT_A_ASGN_TSP which is the importing parameter of the Action ASSIGN_TSP. Populate the parameter as shown below and pass it to the DO_ACTION method.
- Now we update the Status of the Freight Order (TOR). Check if the Actions mentioned above has any importing parameter. If there is, declare a DATA Object by referencing the Importing Parameter. Pass it to the DO_ACTION Method to update the carrier. Remember to call the Transaction manager to save the changes.
- Except Logistical Execution Status which comes under the STOP Node, update the other status like the above steps.
- Update the Logistical Execution Status, get the current stop details using the GET_CURRENT_STOP method of Class /SCMTMS/CL_TOR_HELPER_STOP.
- Declare the Action Parameter by referencing the Importing Parameter of the Action ASSIGN_TSP. Pass the required values to the object. Then call the DO_ACTION Method.
Step 2: Call the RFC from TM System
Once the RFC has been created in TM system, the next course of action is to call the RFC from the ECC system. There are two ways to call this RFC.
One way is to create a custom ABAP program in ECC that will call the RFC. The ABAP program will then be assigned to an Output Type that will get triggered for create/update/delete of shipment.
Another way is to identify a BADI that will get triggered after saving of shipment and then call the RFC from the BADI.
We will proceed with the second option here. You can choose whichever option is suitable for you. The BADI interface is IF_EX_BADI_LE_SHIPMENT. There are three methods in it – AT_SAVE, IN_UPDATE, BEFORE_UPDATE.
We will add our logic to the IN_UPDATE Method. Implement the BADI and create an implementing class and add the below logic.
- Setup RFC destination in ECC and TM system.
- Fetch the RFC destination and save it in a variable of type RFCDEST.
- Check the Importing Parameters of the Method. There are three separate internal tables for each of Shipment Related Tables. Each of the Internal Tables end with suffix like INS or UPD or DEL to distinguish between the different shipment processes like Create, Update and Delete.
- Read the Internal tables to get the Details required to update the Freight Order. Call the RFC and pass the values to the Function.
- There are many VTTK fields corresponding to the status as well as carrier in Freight Order in TM system. Identify the fields and pass them to the RFC.
- This is the entire process to send data from ECC to TM system without any middleware. However, if you are using PI system as your middleware, you do not have to put in this much effort and the data flow is seamless.These Service Providers can get things done easily.1. TransportationOrderSCMExecutionConfirmation_In 2.TransportationOrderSCMExecutionStatusNotification_In
Using RFC is a simple and straightforward way to send data from one SAP system to another. It bypasses the use of middleware and can be highly effective. Check out the solution given above and let me know what you think of it.