So you got this new fancy integration Teamcenter from SAP and Siemens – and you are now wondering what to do. How will you integrate Teamcenter with thew new T4ST component? How should you actually set it up? What are some practical recommendations? This post will not answer everything but based on our recommendations gives some hints and tips. Topics are functional differences, field length limitations, a few words of time and date, a little measure of units, a passing mention of revision handling, user IDs, leapfrogging changes and a little federation. All topics are relevant for all releases – from ECC EHP7 to the latest and greatest SAP S/4HANA 2022, and for all releases of PLMSI. The relevant component on the Siemens side is the T4ST.
Field length illustration from TC Active Workspace
Field length limitations
Fields in Siemens Teamcenter are generally longer than the equivalent fields in SAP S/4HANA – with and without the relevant extensions for S/4. Primary suspects are descriptions and IDs. You can make life a lot easier for Teamcenter users if these known limitations are put in place in Teamcenter PRIOR to the transfer to SAP. It is quite painful when the description of a released component in Teamcenter is too long and everything has to be reworked to cater for the SAP transfer… This applies to all short descriptions. The same goes for classification and variant strings and ID/key fields.
ID handling
Life becomes easier for everybody if an object has the same ID in both systems. Even though we technically support having different IDs, we recommend using the same ID. We have implemented functionality to that respect – by either using an SAP generated ID or by using the Teamcenter ID for both systems. For materials we have also implemented a key reservation functionso you can get IDs from SAP without creating full materials. So – use the same IDs in both systems. Make life easier for everybody in your company – and your customers – so they never have to see two IDs for the same component.
Revisions
Teamcenter has revision handling with each revision being a separate entity with its own lifecycle. This works nicely in a PLM system, but not as easily in a logistics system. From a logistics point of view (think sales order, storage location etc.) – all revisions are the same. We don’t keep track of revision A in shelf 1 and revision B in shelf 2. As an example, this means engineering cannot rely on downstream processes only using rev B for product 123. If you are in a regulated industry, (aerospace, pharma, etc) you should potentially consider using a different material in SAP per revision in Teamcenter. Note that documents in SAP fully support same level of functionality – each revision is a separate entity.
Time and date for changes
For most customers this will be rather obscure – but included for completeness. Teamcenter date effectivity is organized down to plant and time of day with time zone. That means you can indicate that a change is effective from 24th of December 1600 local time at the Oslo plant, but from 0800 the 25th at the Bangalore office. SAP stores a single date for a change – the date the BOM changes are effective from. You can choose to round up or down, but overall this means you might get different dates in the systems.
Unit of measure
SAP natively supports different units of the same dimension – e.g. base unit of measure is KG and BOM item quantity is G – this is supported out of the box without any additional master data. You can also convert between different dimensions of units via alternative units of measure – e.g. 1 roll is 20 meters.
Teamcenter mainly works with a single unit of measure, and there is no native conversion of different units on the part/item and the BOM quantity level. You can configure a workflow in SAP that picks up when a different UoM is used in a BOM compared to the base unit of measure.
Variant configuration
Both SAP and Teamcenter supports some advanced functions/programming/calculations in the variant model. Examples can be calculation of total weight or size. This is not part of the integration, and given the level of complexity will not be on the roadmap in the next few releases. If you depend on features like this, you must implement this in SAP directly. Either the full variant model, or only the formula/programming functions that you need.
Routing & Bill of process structure
Teamcenter allows object dependencies, model unit effectivity, tools and component allocation on the sub operation in a bill of process. For SAP this is all on operation level. You can choose to have the integration create operations in SAP (instead of sub operations). If you do them as sub operations – you will not get that information into SAP.
User ID
The user ID used in SAP is for current releases one user for data creation & maintenance and one for federation. This means there is no proper traceability in SAP for who created something and Teamcenter is your system of records for this.
Model unit/serial number effectivity & DMS documents
Both SAP and Siemens Teamcenter supports a nice set of features for model unit effectivity. Think a valid BOM for a given tail number of a plane, or a change that is valid from serial number 11 and upwards. The integration supports item occurrence effectivity from Teamcenter to the SAP BOM and routing quite nicely.
There is no concept of model unit usage on the material in SAP itself, and hence documents that are controlled using model unit effectivity have to be linked either to the BOM item or be separate entities in the BOM. Same applies for routing – assign it to an operation or as specific PRT and it works, but not directly to the material.
Data Federation
Data federation capabilities exist for most objects. And they are quite OK. That means you can read on demand any information required from SAP rather than storing it in Teamcenter. Sounds great – and it is – but the standard delivery in TC is only delivered for Active Workspace and not the rich client. There is a nice example BADI available for materials that gives cost price and stock levels. Use it productively or enhance it. The Active workspace tab is even clever enough to show whatever is sent without any configuration on the Teamcenter side.
Federated data from SAP shown in Teamcenter
Leapfrogging changes
Sometimes changes happen. Or with Covid still keeping chinese factories closed, they happen more often. With regards to PLM and ERP, particular focus has to be paid attention to the scenario when a later changes overtakes an older one. The illustration is for an item in a BOM.
Change scenario 1
In this scenario, a change is planned to be introduced e.g. 1st of July. The change is planned in january, to allow MRP and other downstream processes to get ample time.
Then you are warned that Item A cannot be procured, and you have to go with C for some time.
CHange scenario – leapfrogging change
This is not natively supported out of the box. You need create your process so that it can support it, by ensuring that you send two change notices to SAP. One to introduce item C, one to obsolete it and let component B back into your BOM again.
Technically related topics
Integrations are always fun with regards to system copies. Both SAP and Teamcenter sends messages to the other system. That means you must pay attention when doing cloning systems or doing client copies in SAP.
Conclusion
This is our short list of annoying pitfalls. It is probably not complete, but it is the ones we’ve seen the most. Take it into account, and save frustration and effort.
This blog post is best understood when read after the other posts:
Overall intro by Arend Weil;
https://blogs.sap.com/2021/11/01/sap-and-teamcenter-integration-the-new-generation-is-released/
Architect Thomas Elsaesser on architecture:
My previous posts on functionality:
R2: https://blogs.sap.com/?p=1529287
As always – comments and questions are appreciated.
