Mis à jour 5 nov. 2026
3 min de lectureMême composant. Contexte différent.
Le fil numérique commence par l’identification de l’objet, de la révision et de l’occurrence observés. Une démarche de diagnostic avant de modifier une nomenclature.
Équipe technique PLM Nexus
- Item Revision ADéfinition commune du composant
- Occurrence 1Chemin X · quantité 1
- Occurrence 2Chemin Y · quantité 2
Schéma du processus
Deux vues montrent le même composant avec une quantité, une position ou une révision différente. Il est tentant de corriger immédiatement la valeur. Vérifiez d’abord si les deux vues décrivent la même occurrence dans la même configuration. L’identifiant de l’item ne suffit pas.
Distinguer l’identité de l’utilisation
Une révision d’item identifie une version du composant. Une occurrence décrit son utilisation dans une structure. Une vue configurée de la nomenclature dépend aussi des règles de sélection et du contexte. Réutiliser un composant n’impose pas la même position ou quantité à chaque utilisation.
Capturer le contexte avant de modifier les données
Consignez l’assemblage supérieur, le chemin vers le composant, la révision sélectionnée, la règle de révision et les paramètres d’effectivité ou de variante applicables. Comparez ensuite la propriété au niveau du composant et de l’occurrence. L’écart devient une question précise et reproductible.
Nos notes sur les occurrences signalent aussi une différence possible entre une modification interactive et une modification par API. Cette observation invite à reproduire les deux parcours dans l’environnement cible ; elle ne constitue pas une règle universelle pour toutes les versions ou propriétés Teamcenter.
Vérifier la modification et ses limites
Utilisez une petite structure de test avec le même composant à deux emplacements. Modifiez uniquement l’occurrence visée, rouvrez la structure et vérifiez les deux chemins. Incluez un second contexte et l’état de cycle de vie pertinent. Une correction automatisée doit s’arrêter si le contexte cible est ambigu, plutôt que deviner la valeur de référence.
Il s’agit de contrôles d’acceptation proposés, pas de tests exécutés ni de résultats clients. Convenez du comportement attendu avec le responsable du processus, notez l’environnement et la version, puis renseignez le résultat observé et la preuve. Une cellule vide ne signifie pas un test réussi.
| Scénario | Résultat attendu | Preuve à conserver |
|---|---|---|
| État initial | Assemblage X → composant A : quantité 1. Assemblage Y → composant A : quantité 2. Même révision, usage différent. | Deux chemins, règle de révision et effectivité. |
| Modification ciblée d’une occurrence | Passez la quantité de X à 3 ; Y reste à 2 et la révision du composant ne change pas. | Rouvrez les deux chemins ; comparez les valeurs enregistrées. |
| Cible ambiguë | L’automatisation s’arrête si le chemin ou la configuration manque. | Requête refusée et structure inchangée. |
Prochaine étape
Si ce schéma apparaît dans votre environnement Teamcenter, découvrez le service correspondant ou discutons du changement nécessaire.