Navigation:  Inventory Management >

Change Proposal

Training Manuals Alphabetical Function List Back Print this Topic Previous topicOne level upNext topic

The use of change proposals is governed by the settings on the Product Master of the selected product code, of the Configuration Item (CI) concerned.  The setting can be varied to "No Control", "Pre-Record Changes for key fields to be changed", and "Record the changes of the key fields to change proposal".

 

Tables currently protected by change proposals are Part Revision, Product Structure, and Part Operations.  With the settings being on the Product Master function, changes on these tables need to be done per approved change proposal (other than for "No Control").

 

The Change Proposal function has four tabs used to define the change, define the tables and activities required on the change proposal, define the key fields on the tables specified, and to route the change proposal to different employees during the evaluation and implementation phases of the change proposal.

 

The Header tab is used to define the changes to be performed.  In order to determine the designer as well as the product definition responsible for the changes, the Configuration Item (CI) the change has an effect on, must be specified.

 

The Configuration Item number is governed by the setting ECP Allow Non MRP Config Items specified on System Configuration. If the setting has a value of "No", the Configuration Item can only be a MRP planned or Phantom Part. If the setting has a value of "Yes", the Configuration Item can only be a MRP and not an MRP planned part.

 

Depending on the setting, ECP Product Code Enforcement on System Configuration the product definition may be overridden.  The product definition also determines the Product Administrator and Product Manager.  These two people, are the only persons allowed to maintain the routing on the change proposal and, with the Designer of the part, maintain the technical description.  Classification of the change proposal is a user defined field that is further described in the Change Proposal Classification function.

 

 

The Linked Tables tab is used to define both the tables on which the changes are to be performed as well as the type of changes.  For Change and Delete transactions, only the table and the type of transaction needs to be selected.  For Add transactions, the number of records to be added must be entered.

 

This only applies to the setting on Product Master Predefine Key fields.  When the setting "ECP Control Applies Key fields to be Predefined" applies to the product code, it is not necessary to predefine the tables, as the tables and key fields will be recorded as the change proposal is implemented.

 

 

The Linked Key Fields tab is used to specify the key fields to be updated.  If the setting on the Product Master for the selected product requires key fields to be predefined, the key fields to be updated by Change or Delete transactions, will have to be predefined before the change can be implemented.

 

If the setting on the Product Master requires the ECP control changes to be recorded, the implementation of the function will insert the key fields on which the changes were implemented.

 

The adding of new key fields will always insert the key fields concerned.  The user can also restrict the persons allowed to implement the changes, defined in the key fields, by appointing an implementor.

 

The Routing/History tab is used to route the change proposal between different participants and the routing is interactive with the mail.  Mail will be sent to participants in the sequence following the sequence with no outstanding actions.

 

The sequence will always start with the Designer of the Configuration Item (CI) identified on the "Header" tab.  After his/her action, mail is sent to the Product Administrator and the Product Manager.  Between the Product Administrator and the Product Manager, they will be able to add new participants on the routing (more than one person can be added as a participant on the same sequence in the routing).

 

The sequence should only be increased if the participant on the higher sequence, is dependent on the actions of the sequence of the participants on the lower sequence.  Mail will prompt the participants on the higher sequence once all participants on the lower sequence have taken action.

 

If a participant cannot perform his/her action without assistance, the participant can task another person.  Participants can only request actions from tasked employees linked to internal actions where the internal action is either "Return with Comments", "Return No Comments", Return Performed", or "Not Yet Actioned", as defined on the function,

Request Action Translation .  Actions taken by the tasked employees will be returned by mail to the Participant.

 

The actions linked to "Internal Actions Reject" and "Final Approval", are the only actions that can influence the status of the change proposal.  Until the change proposal is approved, only "Action Required Not Linked To Internal Action Implement" can be selected.  Once the change proposal is approved, at least one of the internal actions linked to the action required must be implemented.  However, it is possible to use internal actions other than "Implemented", as long as one of the internal actions conforms to the above rules.

 

INQUIRE

The user must have a security profile linked to the function Change Proposal with an access allowed of Inquire.