WijzigingsorderElke versie van een wijzigingsvoorstel heeft een lijst van voorgestelde ingangsdatums die worden vastgelegd in wijzigingsorders. De wijzigingsorders bepalen in Wijzigingsbeheer de ingangsdatums van aan ERP gekoppelde objecten. Een wijzigingsorder staat los van een wijzigingsvoorstel. Wijzigingsorders worden nl. aan een wijzigingsvoorstel gekoppeld. Een wijzigingsorder kan worden geselecteerd voor geldigheidsdatums. Om de geldigheids- en vervaldatums van meerdere wijzigingsorder te beheren kunt u een parent/child-afhankelijkheid tussen twee wijzigingsorders vastleggen. Door hiërarchische relaties tussen wijzigingsorders te definiëren maakt u een wijzigingsorderlijst (WOL) aan. Een parent-wijzigingsorder in een WOL kan children op twee niveaus hebben. U kunt de wijzigingsorders in de WOL koppelen aan het wijzigingsvoorstel. De datum van de parent-wijzigingsorder in de WOL wordt gebruikt als de ingangsdatum voor ERP-objecten die betrokken zijn bij de wijziging en die zijn gekoppeld aan het wijzigingsvoorstel. Als de wijzigingsorderdatum vóór de goedkeuringsdatum valt, wordt de goedkeuringsdatum gebruikt als de ingangsdatum voor alle ERP-objecten die zijn gekoppeld aan het wijzigingsvoorstel. Als de wijziging eenmaal is goedgekeurd, kunnen de datums niet meer worden gewijzigd. Als u de ingangsdatums moet wijzigen, moet de goedgekeurde wijziging worden geannuleerd. Vervolgens maakt u een nieuwe wijziging aan met de nieuwe orderdatums. Wijzigingsorderdatums De wijzigingsorderdatum die wordt weergegeven in de wijzigingsorder, is de datum van de implementatie van de wijziging die wordt beschreven in het wijzigingsvoorstel. Als er sprake is van een afhankelijkheid tussen twee ERP-gerelateerde objecten, wordt de relatieve wijzigingsorder gebruikt om de ERP-gerelateerde objecten geldig te maken of te laten vervallen. Voorbeeld wijzigingsorder CO1 wordt gedefinieerd voor het ERP-gerelateerde object Artikel1 en CO2 voor het ERP-gerelateerde object Artikel2. In de sessie voor betrokken ERP-objecten (Aan wijzigingsvoorstel gerelateerde objecten (dmchm0530m000)) wordt opgegeven dat Artikel1 op 30 juni 2005 vervalt en dat Artikel2 15 dagen na Artikel1 vervalt. De vervaldatum van Artikel2 is afhankelijk van de tijdsduur die voor Artikel1 wordt opgegeven. In dit scenario wordt WO2 dus getriggerd op basis van de datum die is opgegeven met het veld Relatieve wijzigingsorder voor object Artikel1. Datums die zijn opgegeven in WO2 worden hierbij genegeerd. Als u de wijziging goedkeurt en Artikel1 een nieuw object is, wordt Artikel1 geldig op de datum opgegeven in WO1. Als Artikel1 een oud object is, wordt het op die datum op Vervallen gezet. Het veld Relatieve wijzigingsorder voor Artikel1 geeft aan wanneer WO2 wordt gestart. Wanneer WO2 is goedgekeurd, worden datums die zijn opgegeven in WO2, genegeerd. Artikel2 wordt geldig (als het een nieuw artikel is) of op Vervallen gezet (als het een oud artikel is) op de datums die worden aangegeven met het veld Relatieve wijzigingsorder voor Artikel1.
| |||