| # Modification de l'ordre. Une version de la proposition de modification comporte une liste des dates d'application proposées, qui sont enregistrées sous forme d'ordres de modification. Un ordre de modification peut exister indépendamment d'une proposition de modification. Les ordres de modification sont liés à la proposition de modification. Un ordre de modification peut être sélectionné pour des dates d'application. Pour contrôler les dates d'application et d'expiration de plusieurs ordres de modification, vous pouvez définir une dépendance père-fils entre deux de ces ordres. La dépendance hiérarchique entre deux ordres de modification crée une nomenclature des ordres de modification. Une nomenclature d'ordres de modification comporte deux niveaux hiérarchiques. Vous pouvez lier les ordres de modification de cette nomenclature à la proposition de modification. La date de l'ordre de modification fils de la nomenclature est utilisée comme date d'application pour les objets ERP concernés par le changement qui sont liés à la proposition de modification. Si la date de l'ordre de modification est antérieure à celle de l'approbation de la modification, la date d'approbation est choisie comme date d'application pour tous les objets ERP qui sont liés à la proposition de modification. Si la modification est approuvée, les dates de modification ne peuvent pas être révisées. Si vous devez modifier les dates d'application, la modification approuvée doit être annulée. Vous devez créer une nouvelle modification avec de nouvelles dates d'ordre. Dates d'ordre de modification La date qui apparaît dans l'ordre de modification est celle de l'implémentation de la modification décrite dans la proposition de modification. S'il existe une dépendance entre deux objets ERP, l'ordre de modification relatif est employé pour définir ces objets ERP comme applicables ou expirés. Exemple: l'ordre de modification OM1 est défini pour l'objet ERP concerné "article 1" et OM2 est défini pour l'objet ERP concerné "article 2". Dans la session de l'objet ERP concerné, l'article 1 est défini pour expirer à une certaine date, par exemple le 30 juin 05, et l'article 2 est défini pour expirer 15 jours après l'expiration de l'article 2, le 15 juillet 05. La date d'expiration de l'article 2 est fondée sur la durée définie pour l'objet ERP concerné "article 1" dans le champ d'ordre de modification relatif ; cette date annule et remplace toute date indiquée dans l'ordre OM2. Dans ce scénario, l'ordre OM2 est déclenché en fonction de la date indiquée dans le champ Ordre de modification relatif de l'objet concerné "article 1". Si vous approuvez la modification, l'article 1 est défini comme applicable s'il s'agit d'un nouvel article et comme expiré s'il s'agit d'un article existant, selon les dates indiquées dans OM1. Le champ Ordre de modification relatif de l'objet concerné "article 1" contient "OM2". Lors de l'approbation d'OM2, les dates indiquées dans le champ Ordre de modification relatif de l'objet ERP concerné "article 1" annulent et remplacent celles mentionnées dans OM2. Dans le cas où l'article 2 (s'il s'agit d'un nouvel article) est défini comme applicable, l'article 1 prend le statut Expiré. Cette modification est fonction des dates indiquées dans le champ Ordre de modification relatif de l'objet concerné "article 1". Rubriques liées Groupe de tâches |