Dear friends of SAP TM,
Many of you might sooner or later deal with the integration with a SAP S/4HANA TM system. So, in this blog post we will talk about some best practices for the integration of an ECC or SAP S/4HANA system with an SAP S/4HANA TM in a sidecar scenario.
This becomes relevant when you're already running an ECC or SAP S/4HANA system. You've then thankfully decided to use TM functionality within SAP S/4HANA (either in basic or advanced, see this note), may be you want to replace your LE-TRA for transport planning, and connect an SAP S/4HANA as TM system to the existing ECC or SAP S/4HANA.
Frankly spoken, setting up an integration scenario like this one is sometimes not a 'walk in the park'. But obviously the transition should run as smooth as possible to reduce costs, complexity and to save time. To explain respective best practices, the integration scenario mentioned here can basically be split into two parts, master data and transactional data.
Until now, you have used the following master data in ECC or SAP S/4HANA which are also relevant for TM:
Of course, you don't want to set up this master data again in your connected TM system, so you aim to replicate them from ECC or SAP S/4HANA. To do so, DRF (Data Replication Framework) is mandatory when the target system of the replication is an SAP S/4HANA system.
The transfer of this master data to the TM embedded in SAP S/4HANA works as shown in the following pictures:
The relevant transactional data are documents from SD/LE/MM. Thereby you need to decide by customizing, depending on your scenarios, which of those documents should be relevant for TM:
(Example from an ECC EhP8 system)
For any document being relevant for TM, it's then decided in the so-called logistics integration in TM, whether items and schedule lines are transport relevant (see this blog post for more information).
Furthermore, the output determination needs to be set up correctly, so the documents are actually sent to the TM system.
The following steps are mandatory as prerequisite in the TM system:
In addition, the communication per web service to create and update deliveries in ECC / SAP S/4HANA triggered from TM needs to be set up when delivery based integration scenarios are used. Delivery updates are relevant e.g. when the transport planning status changes after a freight unit is assigned to a freight document (see this blog post for details).
Of course, many more settings have to be done in the SAP S/4HANA system where you run your TM. But those are the most obvious ones to integrate your documents from the ECC or SAP S/4HANA.
It's quite common that the master data has different identifiers in the source and target system, e.g. when you work with internal number ranges. This could be an issue when you send your documents from SD/LE/MM to the TM system and don't know the corresponding identifiers in the TM system.
Here, the so-called Unified Key Mapping Service (UKMS) ensures that those master data can be identified in the TM system as shown in the following picture:
During DRF replication, the UKMS is written simply as a matching of the identifiers in the source and target system. Luckily, you don't have to configure or activate anything as it's written automatically during DRF replication.
When now the transactional data arrives at TM, the system looks up the UKMS to fetch the right identifiers of the target TM system, and with those, the processing continues.
In the example above, the data of the sales order is sent to TM with destination location 'A001'. With that, identifier 'ST_A001' is fetched from UKMS as the corresponding identifier in the TM system and the OTR is created accordingly with destination location 'ST_A001'.
If you run an SAP S/4HANA TM in a sidecar scenario, often the question arises, whether several ECC or SAP S/4HANA systems can be connected. And the answer is a solid yes, of course this is possible! And with the UKMS it's ensured that the identifiers of the various systems are matched correctly.
Finally, I want to mention that those best practices and hints are my personal experiences and are no official recommendations or guidelines from SAP.
So, with this information you should have some hints how to start your journey with TM in a sidecar scenario with an ECC or SAP S/4HANA.
Best regards,
Michael
Many of you might sooner or later deal with the integration with a SAP S/4HANA TM system. So, in this blog post we will talk about some best practices for the integration of an ECC or SAP S/4HANA system with an SAP S/4HANA TM in a sidecar scenario.
This becomes relevant when you're already running an ECC or SAP S/4HANA system. You've then thankfully decided to use TM functionality within SAP S/4HANA (either in basic or advanced, see this note), may be you want to replace your LE-TRA for transport planning, and connect an SAP S/4HANA as TM system to the existing ECC or SAP S/4HANA.
Frankly spoken, setting up an integration scenario like this one is sometimes not a 'walk in the park'. But obviously the transition should run as smooth as possible to reduce costs, complexity and to save time. To explain respective best practices, the integration scenario mentioned here can basically be split into two parts, master data and transactional data.
Master data:
Until now, you have used the following master data in ECC or SAP S/4HANA which are also relevant for TM:
- Materials / Products
- Plants / shipping points (ECC) or locations (SAP S/4HANA)
- Customers / vendors (ECC) or business partners (SAP S/4HANA)
Of course, you don't want to set up this master data again in your connected TM system, so you aim to replicate them from ECC or SAP S/4HANA. To do so, DRF (Data Replication Framework) is mandatory when the target system of the replication is an SAP S/4HANA system.
The transfer of this master data to the TM embedded in SAP S/4HANA works as shown in the following pictures:
- For the replication of business partners and locations, web services are used. Materials / products are replicated per IDOC.
- For the materials / products, a source system as ECC (or also SAP S/4HANA) often has much more data then actually needed for TM. See this blog post how to reduce the amount of data replicated to TM.
- If no business partners have been created yet and customers / vendors are still used, the CVI (customer vendor integration) needs to run first. This will create the respective business partners which than can be replicated.
- In an ECC system, no locations exist, only plants and shipping points. Therefore, the respective replication models for plants and shipping points have to be used in DRF. In the target system, the locations are created respectively with the according location type.
- For the replication of products, business partners and locations, web services are used.
- If the source system is an SAP S/4HANA, locations for the business partners could already exist there. If this is the case, the business partners need to be transferred first and only afterwards the locations.
- Hereby it might occur that the location refers to the business partner but has a different address which leads to unwanted results in transport planning. This can happen e.g. when the location is created manually in transaction /SCMTMS/LOC3. Therefore, locations for business partners should never be created manually but only with report /SAPAPO/CREATE_LOCATIONS or during the creation of the business partner as described here. If you have the situation with manually created locations and different addresses, use report /SAPAPO/UPDATE_LOC_ADDRNR to take over the address from the business partner to the location.
- If no locations for business partners exist yet in the source system, they should only be created in the target system after the respective business partners have been replicated. This needs to be done with report /SAPAPO/CREATE_LOCATIONS.
- With business partners, you will likely transfer many data which isn't relevant for TM when the business partner is used in ECC or SAP S/4HANA for other processes as well. This can be an issue when several other master data and settings in customizing would be necessary in the target system even if they are not relevant for TM. How to overcome this obstacle is explained in this blog post.
- If a business partner is used only for a scenario with TM, it should be created in the source system (ECC or SAP S/4HANA) with the minimal amount of data only and then be enhanced with necessary data in the target system.
Transactional data:
The relevant transactional data are documents from SD/LE/MM. Thereby you need to decide by customizing, depending on your scenarios, which of those documents should be relevant for TM:
(Example from an ECC EhP8 system)
For any document being relevant for TM, it's then decided in the so-called logistics integration in TM, whether items and schedule lines are transport relevant (see this blog post for more information).
Furthermore, the output determination needs to be set up correctly, so the documents are actually sent to the TM system.
The following steps are mandatory as prerequisite in the TM system:
- Define TRQ types for OTR/DTR, depending if you use order based / delivery based integration scenarios
- Define respective conditions so those TRQ types can be found (Planning -> Profiles and Settings -> Create Condition)
- Define freight unit types
In addition, the communication per web service to create and update deliveries in ECC / SAP S/4HANA triggered from TM needs to be set up when delivery based integration scenarios are used. Delivery updates are relevant e.g. when the transport planning status changes after a freight unit is assigned to a freight document (see this blog post for details).
Of course, many more settings have to be done in the SAP S/4HANA system where you run your TM. But those are the most obvious ones to integrate your documents from the ECC or SAP S/4HANA.
Unified Key Mapping Service
It's quite common that the master data has different identifiers in the source and target system, e.g. when you work with internal number ranges. This could be an issue when you send your documents from SD/LE/MM to the TM system and don't know the corresponding identifiers in the TM system.
Here, the so-called Unified Key Mapping Service (UKMS) ensures that those master data can be identified in the TM system as shown in the following picture:
During DRF replication, the UKMS is written simply as a matching of the identifiers in the source and target system. Luckily, you don't have to configure or activate anything as it's written automatically during DRF replication.
When now the transactional data arrives at TM, the system looks up the UKMS to fetch the right identifiers of the target TM system, and with those, the processing continues.
In the example above, the data of the sales order is sent to TM with destination location 'A001'. With that, identifier 'ST_A001' is fetched from UKMS as the corresponding identifier in the TM system and the OTR is created accordingly with destination location 'ST_A001'.
If you run an SAP S/4HANA TM in a sidecar scenario, often the question arises, whether several ECC or SAP S/4HANA systems can be connected. And the answer is a solid yes, of course this is possible! And with the UKMS it's ensured that the identifiers of the various systems are matched correctly.
Finally, I want to mention that those best practices and hints are my personal experiences and are no official recommendations or guidelines from SAP.
So, with this information you should have some hints how to start your journey with TM in a sidecar scenario with an ECC or SAP S/4HANA.
Best regards,
Michael
- SAP Managed Tags:
1 Comment
| User | Count |
|---|---|
| 6 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
