community-knowledge
Effectivity Management Complexity & Implementation Pitfalls
Source type: independent practitioner blogs (TCPLMBASICS, Saratech) and search-aggregated community/forum discussion. Where a source could not be directly fetched, this is noted explicitly rather than fabricated.
Occurrence Effectivity — core mechanics (TCPLMBASICS)
Occurrence Effectivity configures product structures by date, unit number, or both. Effectiveness information lives in dedicated effectivity objects that structure occurrences reference — an occurrence with no effectivity assignment stays perpetually active.
Key mechanic: "Sharing effectivity means, any change to effectivity object in date or unit number, affects all occurrences referencing this effectivity object." This centralizes updates but means changes ripple to every referencing occurrence — a source of surprise if not understood.
- Occurrences can be copied while preserving effectivity settings.
- Effectivity can be removed from one occurrence without affecting others sharing the same object.
- The CFMOccEffMode preference controls whether date effectivity, unit-number effectivity, or both are allowed.
- Multi-unit configuration lets a single occurrence associate with multiple unit numbers/end items simultaneously, saved as non-revisable effectivity groups (enabled via the Fnd0EnableMultiUnitConfiguration constant).
Notable pitfall called out by the practitioner: multi-unit configurations use OR logic, not AND logic — an occurrence loads if any condition in an effectivity group matches, which prevents duplication but limits precise filtering in complex scenarios. This is a subtle behavior that can surprise engineers expecting AND semantics.
Source: Occurrence Effectivity in Teamcenter — TCPLMBASICS
Revision effectivity vs. occurrence effectivity — general guidance
Aggregated search-result guidance (from general PLM/Teamcenter discussion, not a single deep-dive source): using both revision effectivity and occurrence effectivity on the same product simultaneously is generally discouraged because "the compounding of the two is unduly complex." Revision effectivity is described as simpler and easier to manage than occurrence effectivity, and is the recommended default unless occurrence-level granularity is genuinely required.
Effectivity granularity mismatch with ERP (Teamcenter–SAP integration)
A cross-system pitfall surfaced in SAP Community discussion of Teamcenter–SAP PLM integration: Teamcenter date effectivity can be organized down to plant and time-of-day with time zone, while SAP stores a single date for a change — meaning the two systems can effectively disagree on "the date" for the same effectivity event unless integration mapping accounts for this. Additionally, SAP has no native concept of model-unit usage on a material, so documents controlled by model-unit effectivity in Teamcenter have to be linked either to the BOM item or kept as separate entities on the SAP side. Both systems support advanced variant-model calculations (e.g., total weight/size), but this was explicitly called out as not part of the standard Teamcenter–SAP integration and unlikely to be roadmapped "in the next few releases" (per that source, as of its publication).
Source: PLM System integration - Teamcenter and SAP - pitfalls and recommendations (SAP Community)
Configuration/revision-rule sprawl
A recurring implementation warning (aggregated from search results, general Teamcenter configuration-management guidance): the mainstream BOM definition should be kept "as simply as feasible." If the product definition accumulates every iteration of every study and design alternative, the configuration logic becomes very complex — usually showing up as either very complex revision rules or a proliferation of revision rules across the install. This is described as a common root cause of BOM-configuration performance and maintainability problems, distinct from raw data-volume issues.
BOM explosion performance
A Siemens Community support forum thread titled "Bom explosion in Structure Manager is very slow 10.1" exists (surfaced via web search), indicating this is a known, discussed pain point among practitioners on older Teamcenter versions (10.1-era). The thread's actual content could not be retrieved — community.sw.siemens.com pages returned only a client-side "CSS Error / Refresh" placeholder on WebFetch, a known access limitation for that site (also encountered when trying to read a related "eBOM and mBOM configuration management" community article). This is noted honestly rather than fabricating thread content; the existence and framing (a support question specifically about slow BOM explosion) is the only verified fact.
Related Siemens-side product framing (from the Usage BOM posts, see structure-bom-usage-bom-2512.md) directly acknowledges this class of problem: "loading multi-thousand-line structures can feel slower, grinding productivity to a halt" with traditional Assembly BOM, which Usage BOM's flatter occurrence-centric structure is positioned to address in Teamcenter 2512.
Data quality / migration pitfall
General implementation guidance aggregated from search results: "poor data can break even the best PLM system" — legacy data must be cleaned, structured, and validated before migration into Teamcenter, a pitfall that applies broadly to BOM/structure migrations specifically because bad parent-child relationships or duplicate part numbers propagate directly into BOM explosion correctness.
Notes / caveats
- The TCPLMBASICS post is the one clearly practitioner/independent (non-Siemens) source with real technical depth in this file.
- The SAP Community post is vendor-adjacent (SAP, not Siemens) but is independent of Siemens and offers a genuinely different-vendor perspective on integration pitfalls.
- Several points above are aggregated from WebSearch result snippets rather than a full article read (noted per-section); no statistics or quotes were invented — where a claim could not be traced to a specific retrievable source, it is presented as general/aggregated guidance rather than attributed to a named article.