| Q : | Pourquoi faut-il réaliser une cartographie ERP ? |
| R : | Un petit exemple peut illustrer cette nécessité : Suite à des modifications dans une version ultérieure du catalogue, il se peut par exemple qu'un projet ait été scindé en deux. Si le client installait simplement la nouvelle version du catalogue, les numéros ERP existants tomberaient dans le vide, car le projet initial n'existerait plus. Mais si un mapping est créé, l'information est disponible lors de l'installation et les numéros ERP peuvent être correctement attribués aux deux nouveaux projets. |
| Q : | Sur quelles versions le mapping est-il basé ? |
| R : | |
| Q : | Est-il possible d'exécuter une cartographie ERP pendant qu'une publication LIVE est en cours ? |
| R : | Non. Un nouveau mapping est toujours créé par rapport à la dernière publication LIVE, mais celle-ci n'est pas encore disponible. |
| Q : | Quand faut-il ajouter un mappage ERP pour la publication partielle (commande du menu contextuel Ajouter un mappage ERP pour la publication partielle. [Add ERP mapping for partial publication....]..) ? |
| R : | Pour une publication QA qui ne contient que les fichiers modifiés localement dans le sous-dossier sélectionné. Tous les autres fichiers sont utilisés à partir de la dernière publication QA réussie. De cette manière, seul un sous-ensemble de fichiers modifiés localement peut être publié. En exécutant différentes publications partielles avant d'exécuter une publication en direct, il est possible de composer une version en direct spécifique souhaitée. Par exemple : User1 exécute une publication partielle pour le sous-dossier 1, User2 une publication partielle pour le sous-dossier 2, etc. |
| Q : | Le modeleur a vérifié des mappings sans les avoir réellement vérifiés - Comment cela peut-il être corrigé ? |
| R : | Cela peut entraîner des problèmes lors de l'installation d'une mise à jour du catalogue. La publication LIVE fonctionne parce qu'il existe des mappings. Mais lorsque le client installe la mise à jour, les numéros ERP peuvent être mappés sur des pièces incorrectes. Solution : créez une nouvelle publication en direct et pour celle-ci deux mappings : Créer un mapping comme d'habitude (la version source correspond à la dernière version live disponible) Supprimez le mapping confirmé par erreur du fichier de mapping (commande de menu contextuel Nettoyer les mappings ERP pour les anciennes versions [Cleanup previous ERP mappings...]...). Créez un deuxième mapping sur l'avant-dernière version live.
|
| Q : | Que se passe-t-il lorsqu'une variable utilisée pour le mappage ERP est supprimée ? |
| R : | Le mapping est basé sur une ligne entière. Il ne se passe donc pas grand-chose. L'utilisateur doit vérifier la proposition de mapping. |
| Q : | A quoi faut-il faire attention en ce qui concerne les liens ? |
| R : | Rien, car les liens n'apparaissent pas dans le mapping. Un lien pointe vers un projet réel. Mais si le projet réel est modifié, celui-ci a besoin d'un mapping. Ainsi, tout est également en ordre pour le projet de lien. |
| Q : | Quels catalogues nécessitent une cartographie ERP ? |
| R : | Uniquement les catalogues pour lesquels un CIP est créé pendant la publication LIVE (case à cocher dans le dialogue). Les catalogues sans CIP n'ont pas de numéros ERP. Dans PARTcommunity ou 3dfind.it, les projets sont simplement mis à jour. Il n'y a pas de numéros ERP dans ces applications, qui sont la seule raison du mappage ERP. |
| Q : | L'exécution de la modification de la cartographie ERP.. [Edit ERP-Mapping...]. est une méthode fiable pour vérifier le mappage ERP d'une autre personne (également dans le cadre de contrôles AQ) ? |
| R : | Oui, mais il faut tenir compte de ce qui suit : La cartographie ERP est créée sur la base de la copie de travail locale du catalogue. Vous devez donc vous assurer que c'est la même (attention aux fichiers modifiés localement, obsolètes). |
| Q : | Certains problèmes de cartographie ERP sont difficiles à reproduire - Quelle est la meilleure façon de les rapporter ? |
| R : | mapping.json Si possible, ne modifiez pas d'autres fichiers, sinon il sera encore plus difficile de vérifier le problème). Quel type de modifications a été effectué et a conduit au problème de cartographie ? N'utilisez pas de solutions de contournement si la publication échoue, comme par exemple Publier sans CIP, pour effectuer la publication. Publier sans CIP détruit les données du serveur.
|
| Q : | Quel est le rôle des fichiers téléchargés dans le trunk SVN (Télécharger les fichiers modifiés dans les répertoires/projets sur le serveur [Upload changed files in directories / projects to the server] ) dans la publication de l'assurance qualité ? |
| R : | En fait, aucun, car ce sont les fichiers de la copie de travail locale qui sont utilisés. (Quant à savoir s'il est judicieux de ne pas archiver les fichiers locaux, c'est une autre question). |
| Q : | Où le mapping est-il enregistré ? |
| R : | Dans
du fichier mapping.json. |
| Q : | Le fichier peut-il être mapping.json par plusieurs utilisateurs ?
en même temps ? |
| R : | Oui, le fichier n'est pas verrouillé. Pour avoir un état le plus actuel possible, actualisez votre fichier local. |
| Q : | Comment éviter efficacement les conflits ? |
| R : | Téléchargez toujours la dernière version du
mapping.json fichier
en bas. Il est préférable de toujours effectuer des mappages lors de l’enregistrement
et vérifiez dans le mapping.json .
Cela devrait garantir que les mappages sont toujours à jour
Et la publication est alors possible sans aucun problème. Archiver les modifications le plus rapidement possible (+ créer un mapping pour celles-ci). Si, par exemple, une modification importante doit être effectuée, il peut être plus judicieux d'effectuer cette modification en plusieurs petites étapes et d'archiver les modifications après chaque étape partielle (+ créer un mapping et l'archiver).
|
