| Agile Product Lifecycle Management Product Collaboration User Guide Release 9.3.5 E61150-03 |
|
 Previous |
 Next |
| Agile Product Lifecycle Management Product Collaboration User Guide Release 9.3.5 E61150-03 |
|
Previous |
Next |
The following classes, or types, of changes are available in Agile PLM:
Change Orders class, including engineering change orders (ECOs) and Design File Change Orders (DFCOs)
Change Requests class, including engineering change requests (ECRs)
Manufacturer Orders class, including manufacturing change orders (MCOs)
Site Change Orders class, including site change orders (SCOs)
Deviations class
Stop Ships class
Each Agile PLM class has at least one out-of-the-box subclass. The Agile administrator may decide to use some or all of these change classes and subclasses, and may have created additional subclasses. For example, under the Change Orders class, you might have ECOs, Mechanical ECOs, Software ECOs, and so on.
The purpose of each change subclass is listed in the following table. Corresponding change icons are also listed. These icons are displayed next to the change number on the Changes tab of the item, and next to each change in search results.
Table 7-1 Change subclasses
| Change type | Purpose |
|---|---|
|
Change Order: ECO
(Web Client)
(Java Client) |
An engineering change order tells users that changes need to be made to specific items, and to go ahead and do the work required to make those changes. ECOs create a new, trackable revision of an item. ECOs can affect common and site-specific portions of the BOM and AML. ECOs allow you to: Release new items. Create revision-specific redline modifications to BOMs, to manufacturer data, and to attachments. Create change-controlled redline modifications to item attributes. |
|
Change Order: DFCO Web Client only |
The Design File Change Order (DFCO) change order subclass is used to publish Design files. The DFCO has an Affected Files tab. Typically, DFCOs are used in conjunction with Agile Engineering Collaboration, which connects Agile PLM with your CAD system environment. The DFCO subclass is available only if your Agile administrator has enabled it. |
|
ECR
(Web Client)
(Java Client) |
An engineering change request is used to request a change to be made to items. You can create an ECR against a non-latest released revision of an item. |
|
MCO
(Web Client)
(Java Client) |
A manufacturer change order tells users that changes need to be made to the manufacturing data of specific items. MCOs can affect common and site-specific portions of the AML. MCOs allow you to: Release new items. Redline the manufacturer data of an item. Change the lifecycle phase of items. Create change-controlled redline modifications to item attributes. |
|
SCO
(Web Client)
(Java Client) |
A site change order tells users that changes need to be made to site-specific items, and to go ahead and do the work required to make those changes. SCOs affect only the site-specific portion of the BOM and AML. They do not affect the common portion of the BOM and AML. You can create an SCO against a non-latest released revision of an item. SCOs let you redline BOMs and AMLs. |
|
Deviation
(Web Client)
(Java Client) |
A deviation is used to deviate from a process or specification for a specific time period. You can create a deviation against a non-latest released revision of an item. Deviations do not have any redlining functions. |
|
Stop Ship
(Web Client)
(Java Client) |
A stop ship alerts users to stop shipping or using an item. You can create a stop ship against a non-latest released revision of an item. Stop ships do not have any redlining functions. |
For information about changing the subclass of a change, see the chapter about workflows in Getting Started with Agile PLM.
This section includes the following topics:
When you view a change in Web Client, information about the change is displayed on tabs in the right pane, the content pane.
When you view a change in Java Client, information about it is displayed on tabs in its object window.
The following table shows the tabs and the default fields for changes.
The Agile administrator may have added additional tabs or sections, called Page Two and Page Three by default. (The Agile administrator may have renamed these tabs in your Agile PLM system.) These tabs or sections contain custom fields defined by the administrator.
Table 7-2 Change object tabs
| Tab name | Tab information includes |
|---|---|
|
Cover Page |
General information about the change plus any unique fields defined by the Agile administrator. |
|
Affected Items |
Which items are affected by the change. ECOs include redlined BOMs, AMLs, and file folders. SCOs include redlined BOMs and AMLs for a site. MCOs include redlined AMLs. ECOs and MCOs also include change-controlled redlined item attributes. |
|
Affected Files |
Which file folder files are affected by the DFCO. |
|
Workflow |
Approvers, observers, and acknowledgers of the change and the results of their reviewing the change. The statuses of the workflow. |
|
Relationships |
The Relationships tab lets you create relationships and dependencies between the current change object and other Agile PLM objects, both routable objects and lifecycle objects. For more information about relationships, see Getting Started with Agile PLM. |
|
Attachments |
Attached files and URLs. |
|
History |
A record of the actions taken on the change. |
The Cover Page tab of a change shows the information traditionally shown on a paper ECO form. Agile PLM completes some fields and then you complete the rest of the fields.
This section contains the following topics:
To edit fields on the cover page tab in Web Client:
Click the Edit button, modify the fields, and then click the Save button.
To edit fields on the Cover Page tab in Java Client:
Modify the fields and click Save.
Sometimes you cannot edit a field. A field may be uneditable for three reasons:
You do not have sufficient privileges to modify that field.
The field is automatically filled in as the change progresses through its workflow statuses, for example, Status, Date Released, or Final Complete Date.
The field may not be edited when a certain event has occurred - for example, the Workflow field cannot be edited after the workflow has moved out of the Pending status.
For information about all change object tabs, see "Change Objects."
The following table summarizes the Cover Page fields and the information that they contain. The fields on the Cover Page tab vary from one change type to another.
In Web Client, the Cover Page can contain two additional sections, called Page Two and Page Three by default. In Java Client, these are separate tabs. The Agile administrator determines whether these sections are enabled, and what they are called.
Table 7-3 Cover Page tab fields
| Field | How completed | Contents |
|---|---|---|
|
Number |
Usually automatically, when created, but may be configured for manual entry. |
The number assigned to the change when you create it. |
|
Status |
Automatically, when created, updated as the change moves through the assigned workflow. |
Change status, described in "Status on the Cover Page Tab." If no workflow has been selected, then this field is Unassigned. |
|
Change Type |
Automatically, when created. |
The type of change selected when you create the change. |
|
Change Category |
Usually manually, can contain a default. |
Category defined by the Agile administrator (can be selected from a drop-down list). |
|
Description Of Change |
Usually manually, can contain a default. |
Maximum number of bytes is set by the Agile administrator, can be up to 4000 bytes, including spaces and carriage returns (which count as 2 bytes). Non-English characters can be 2, 3, or 4 bytes. |
|
Reason For Change |
Usually manually, can contain a default. |
Maximum number of bytes is set by the Agile administrator, can be up to 4000 bytes, including spaces and carriage returns (which count as 2 bytes). Non-English characters can be 2, 3, or 4 bytes. |
|
Reason Code |
Usually manually, can contain a default. |
Code defined by the Agile administrator (can be selected from a drop-down list). |
|
Workflow |
Automatically (if only one workflow applies to the change), when the change is moved to the next status from the Unassigned status. If more than one workflow applies to the change, then the workflow is selected manually, the workflow selection can be changed only if the change is in the Pending status type. Selecting the blank field in the Workflow drop-down list switches the change to the Unassigned status. |
The name of the workflow being used to move this change through the change control process. |
|
Change Analyst or Component Engineer |
May be provided automatically by the workflow. If you have the appropriate Modify privilege, then the routing manager can be selected manually from an address book list of change analysts or component engineers. |
Default routing manager. If the workflow is defined to notify the default change analyst or component engineer, then the user in this field receives notifications about the change. If this field is left blank, then the notifications are sent to every change analyst or component engineer on the list. If the notification definition in the workflow is blank, then no notifications are sent. |
|
Originator |
Usually automatically, when created (with the default set by the Agile administrator). |
The user who created the change (can be selected from a drop-down list). |
|
Date Originated |
Usually automatically, when created. |
The date the change was created. |
|
Date Released |
Automatically, when released. |
The date the change was released. |
|
Final Complete Date |
Automatically, when the change enters the Complete status Type. |
The date the change moved into the Complete status Type. |
|
Product Line(s) |
Usually manually, can contain a default. |
Product line defined by the Agile administrator (can be selected from a drop-down list). |
|
Functional Teams |
Manually. |
One or more Functional Teams that are used to assign approvers, observers, and acknowledgers according to work place job functions. For more information about functional teams and the approval matrix feature, see Agile PLM Administrator Guide and Getting Started with Agile PL M. |
|
Effective From |
Manually. |
Deviations only. The date the deviation goes into effect. |
|
Effective To |
Manually. |
Deviations only. The date the deviation is no longer in effect. |
|
Resume Date |
Manually. |
Stop Ships only. The date the stop ship is no longer effective and the company can resume shipping of the item. |
The Cover Page tab for deviations has two unique fields, Effective From and Effective To. The Cover Page tab for stop ships has one unique field, Resume Date.
The Cover Page tab for MCOs has a Component Engineer field (in the place of a Change Analyst field).
For information about all change object tabs, see "Change Objects."
If the workflow specifies a Default Change Analyst, then the Change Analyst field is automatically populated by the workflow, even if you do not have Modify privilege for the Change Analyst field.
A label in the top right corner of a change indicates the status of the change. The Agile administrator defines the name of each status in each workflow.
|
Note: The Agile administrator may have created customized workflows and statuses for your company. The table below lists only the 12 Agile PLM default workflow statuses. |
Table 7-4 Default Workflow status definitions
| Status name | Status definition |
|---|---|
|
Unassigned (no status type) |
No workflow has been assigned to this change. The originator may still be developing the change. No statuses are displayed on the Workflow tab. |
|
Pending (Pending status type) |
The originator may still be developing the change. It has not yet been approved or perhaps even completed. |
|
Submitted (Submit status type) |
The change has been routed to the change analyst or component engineer for review and analysis. |
|
CCB (Review status type) |
The change has been routed to the members of the change control board (CCB) for approval. |
|
Released (Released status type) |
The change has been signed off by the CCB members and released. |
|
Closed (Complete status type) |
The change is an ECR that has been accepted and implemented. |
|
Expired (Complete status type) |
The change is a deviation where the Effective To date has been reached. |
|
Implemented (Complete status type) |
The change is an ECO or SCO that has been implemented or incorporated into new drawings. |
|
Hold (Hold status type) |
The change has been placed on hold while information is being gathered by the component engineer. |
|
Resumed (Complete status type) |
The change is a stop ship that has been lifted. Production of affected items can resume. |
|
Canceled (Cancel status type) |
The change has been canceled due to a fundamental flaw or rejection by several people. |
|
First Article Complete (Complete status type) |
The manufacturer part has been received and passed incoming inspection or quality assurance. The physical part has been validated against design documents or specifications (MCO only). |
|
Note: Both Released and Complete status types are considered as the laststatus types in the workflow. |
The Workflow tab shows all the statuses the change has been through, and the statuses remaining to complete the change control process. See "Workflow Tab."
With appropriate privileges, you can switch a change to another status with the Workflow tab or the Next Status button. For more information, see the chapter on workflows in Getting Started with Agile PLM.
For information about all change object tabs, see "Change Objects."
The Affected Items tab lists the items that are affected by a change. Users with sufficient privileges can complete the Affected Items tab and use it to redline BOMs, manufacturing data, and attachments. Also, on the Affected Items tab of ECOs and MCOs, you can create change-controlled redline modifications to item attributes.
|
Note: If you do not have Discovery and Read privileges for an item, then it does not appear on the Affected Items tab. You may see a message telling you how many items are not displayed. |
To open an item listed on the Affected Items tab:
In Web Client, click the item number link. The item opens with the Title Block tab on top. Alternately, you can use the Quick View feature to display Title Block attributes and attachment information of an item. Hover the cursor over the item link, and when the Quick View tooltip appears, click the tooltip to open the Quick View palette.
In Java Client, double-click the affected item row. The item opens with the Title Block tab on top.
Or, right-click the item row, choose Open, and then choose a tab. The item opens with the selected tab on top.
The revision associated with the change is selected in the Rev drop-down list.
For information about all change object tabs, see "Change Objects."
For information about working with Affected Items tabs, see the chapter, Chapter 8, "Affected Items of Changes."
The Affected Files tab is an optional change object tab; it is visible only if the Agile administrator has enabled it for a specific change subclass. The Affected Files tab is visible on the Design File Change Order (DFCO) subclass. Typically, DFCOs are used in conjunction with Agile Engineering Collaboration, which connects Agile PLM with your CAD system environment.
DFCOs use the Agile PLM workflow process to submit file folders and the files they contain for publication, to redline and update those files, to route them for signoff approval, and then to publish the files folders with a specified LifeCyle Phase and a specific Version number and Publication Sequence number.
For more information about the Affected Files tab and the Design File change process, see:
Getting Started with Agile PLM, chapter "Working with Design File Change Orders (DFCOs)"
Agile PLM Administrator Guide, chapter "Administering Design File Change Orders (DFCOs)"
Agile Engineering Collaboration 3.5 Documentation:
http://www.oracle.com/technetwork/documentation/agile-085940.html#ec
The Workflow tab shows all the statuses the change has passed through, and which statuses remain to be completed. It also shows all the approvals, rejections, and acknowledgments made during each approval cycle.
For example, suppose a change is returned to the originator, reworked, and then resubmitted for a second approval cycle. The Workflow tab shows the approvals, rejections, and acknowledgments of the change made during the first approval cycle, and during the second approval cycle.
Depending on where the change is in the workflow, the Workflow tab can have up to three sections:
For information about all change object tabs, see "Change Objects."
The top section of the Workflow tab (visible for all changes that have been assigned a workflow) displays the name of the assigned workflow and a flowchart of the workflow. The current status of the change is highlighted in the flowchart.
Some of the statuses in the flowchart are links. Links are underlined. You can switch the change to one of these statuses by clicking the link and filling in the Notify field. You need sufficient privileges to do this.
In Web Client, the status with an orange background is the current status. At the top of the Summary flowchart pane, click to hide the flowchart, or click to display the hidden flowchart.
In Java Client, the status with a yellow background is the current status. At the top of the flowchart pane, click the Hide/View workflow chart button to hide the flowchart or view a hidden flowchart.
The ability to add or remove approvers, observers, or acknowledgers is controlled by the Ad Hoc Reviewers property settings for each workflow. In addition, you must have the appropriate privileges to add or remove approvers, observers, or acknowledgers. If the Agile administrator has not granted the appropriate privileges to you, then the buttons on the Workflow tab are not available, and you cannot perform the actions.
In Web Client:
The Add Reviewers and Remove Reviewers buttons appear at the top left of the Workflow table. Click the button for the action you want to perform, and then follow the dialog instructions.
In Web Client, the Resolve Missing User action also adds a reviewer to the workflow table. When the Missing User icon appears in the Reviewer cell of the workflow table, double-click inside the cell where the icon appears and specify a job function user for the missing reviewer. For more information, see Getting Started with Agile PLM, "Routing Objects with Workflows" chapter.
In Java Client:
The Add Approvers/Observers and Remove Approvers/Observers buttons appear at the top left of the Workflow tab. To add approvers or observers, and click and select the workflow status you want in the dialog. To remove an approver or observer, click and choose the status you want in the dialog.
The Web Client workflow table shows the status information for the change, including the signoff information for past, current, and future signoff statuses. It has the following columns by default. The Agile administrator may have modified the table:
Status Code - icon indicating the action or state for the status table row.
Table 7-5 Workflow status code icons
| Icon | Definition |
|---|---|
|
|
Future. The change workflow has not yet moved to this status. |
|
|
Current. The workflow status of the change, the workflow is currently in this status. |
|
|
Forward. The change moved forward to the next status in the workflow. |
|
|
Backward. The changed moved backward in the status list of the workflow. For example, when the Change Analyst returns the change to the originator, the change moves backward in the workflow. |
|
|
Skip. The change skipped a status as it moved forward in the workflow. |
Workflow - the name of the workflow that the change is following.
Workflow Status - the name of the status.
Action - the action taken by the reviewer.
Req'd - whether the reviewer is a required reviewer (approver or acknowledger) or not (observer).
Reviewer - the user who reviewed the change. This can be an approver, an acknowledger, or an observer, and it can be a single user or a user group.
Signoff User - the name of the user who actually approved, acknowledged, or rejected the change.
Status Changed By - the name of the user who switched the status.
Local Client Time - the date and time of the action.
Signoff Comments - any comments made by the reviewers (approvers, acknowledgers, and observers) during signoff.
Reviewer Job Function - the assigned job function of the reviewer as defined in the functional team.
Signoff Duration - the number of days the reviewer has taken to sign off the change for that status.
User Action Time - This is the date and time on the computer where the action was performed. See "User Action Timestamp."
See also "Workflow Tab," "User Action Timestamp," "Signoff Duration."
In the Views drop-down list, choose Current Sign-off Status to view only the signoff information for the current Review-type or Release-type status. If the current status is not a review or release status, then no data is displayed for this view.
The Current Signoff Status view has the following columns by default. The Agile administrator may have modified the table
Status Code - icon indicating the action or state for that table row, not used in the Current Status View.
Workflow - the name of the workflow that the change is following.
Workflow Status - the name of the status, not used in the Current Signoff Status View.
Action - the action taken by the reviewer.
Req'd - whether the reviewer is a required reviewer (approver or acknowledger) or not (observer).
Reviewer - the user who reviewed the change. This can be an approver, an acknowledger, or an observer, and it can be a single user or a user group.
Signoff User - the name of the user who actually approved, acknowledged, or rejected the change.
Status Changed By - the name of the user who switched the status.
Local Client Time - the date and time of the action.
Signoff Comments - any comments made by the reviewers during signoff.
Signoff Duration - the number of days a reviewer has taken to sign off the change for that status.
Reviewer Job Function - the assigned job function of the reviewer as defined in the functional team.
See also "Workflow Tab," "User Action Timestamp," "Signoff Duration."
The Summary table records the transition of the change through the workflow statuses and the signoff information for the each review-type status or released-type status. It has the following columns by default. The Agile administrator may have modified the table:
Action - the action taken by the reviewer.
Req'd - whether the reviewer is a required reviewer (approver or acknowledger) or not (observer).
Reviewer - the user who reviewed the change. This can be an approver, an acknowledger, or an observer, and it can be a single user or a user group.
Signoff User - the name of the user who actually approved or rejected the change.
Local Client Time - the date and time of the action.
Signoff Comments - any comments made by the reviewers during signoff.
Signoff Duration - the number of days a reviewer has taken to sign off the change for that status.
Reviewer Job Function - the assigned job function of the reviewer as defined in the functional team.
See also "Workflow Tab," "User Action Timestamp," "Signoff Duration."
The Signoff History table of the Workflow tab lists and signoff information for the current Review-type or Release-type status. If the current status is not a review or release status, then the Signoff History table is not displayed.
The Signoff History table has the following columns by default. The Agile administrator may have modified the table:
Workflow - the name of the workflow that the change is following.
Workflow Status - the name of the status.
Action - the action taken by the reviewer.
Req'd - whether the reviewer is a required reviewer (approver or acknowledger) or not (observer).
Reviewer - the user who reviewed the change. This can be an approver, an acknowledger, or an observer, and it can be a single user or a user group.
Signoff User - the name of the user who actually approved, acknowledged, or rejected the change.
Status Changed By - the name of the user who switched the status.
Local Client Time - the date and time of the action.
Signoff Comments - any comments made by the reviewers during signoff.
Signoff Duration - the number of days a reviewer has taken to sign off the change for that status.
Reviewer Job Function - the assigned job function of the reviewer as defined in the functional team.
See also "Workflow Tab," "User Action Timestamp," "Signoff Duration."
Signoff Duration data is recorded for statuses that have reviewers: Review-type statuses and Release-type statuses. Signoff Duration records time in a manner similar to a stop watch or timer. The recorded time indicates either how long each reviewer has been able to signoff the change for that status, but has not yet done so, or the number of days it took the reviewer to signoff the change for that status.
Signoff Duration is recorded for each user in days. It is the lesser of:
Time since the change entered the workflow status. The time is recorded for the most recent entry into the status.
Time since the user was last added to this workflow status.
The Signoff Duration timer begins recording duration time when the user becomes a reviewer, either when the change enters the signoff status or the user is added as a reviewer to the signoff status.
The signoff duration timer continues to increment one day at a time. The timer freezes when:
The reviewer signs off the change for that status.
The change exits that status
If the change enters a specific signoff status multiple times, then a separate duration is recorded for each time the change enters the status.
Signoff Duration time is recorded in days. When a change enters a signoff status, if a reviewer signs off within the first 24 hours, then the Signoff Duration time is recorded as 0 (zero).
Agile PLM provides two ways to record the date and time of any action taken against the change:
Local Client Time - This is the date and time as shown on the local client computer of the user who is viewing the timestamp. Local client time is the default method of viewing timestamps.
For example, if Mary approves a change at 12 noon in New York (Eastern Time), then when John looks at the Workflow tab of the change in California, he sees the time Mary approved the change as 9 o'clock in the morning (Pacific Time).
User Action Time - This is the date and time on the computer where the action was performed. User action time is optional.
If Mary approves a change at 12 noon in New York, then when John in California looks at the Workflow tab of the change, he sees the following:
In the Local Client Time column, the time Mary approved the change is 9 o'clock in the morning (Pacific Time).
In the User Action Time column, the time Mary approved the change is 12 noon (Eastern Time).
When Mary looks at the Workflow tab of the change, she sees the following:
In the Local Client Time column, the time she approved the change is 12 noon (Eastern Time).
In the User Action Time column, the time she approved the change is 12 noon (Eastern Time).
Local Client Time always appears on the Workflow tab and History tab. User Action Time is optional, and is displayed on the Workflow tab of changes and the History tab of any Agile PLM object only if the Agile administrator specifies this.
See also: "Workflow Tab."
The item object Relationships tab lets you create relationships with other business objects, both lifecycle objects and routable objects. If the related object is a routable object, then you can specify a rule for the relationship, thus creating a dependency between the current item and the routable object. A relationship with a rule indicates a routable object whose workflow progression is affected by the lifecycle phase of the current item object.
A relationship with no specified rule does not limit or affect the workflow progression of the related routable object. You can use non-rule relationships to record objects that are somehow related to the current item, but do not have any dependencies with the current item.
|
Note: You cannot specify a rule for an item relationship with another lifecycle phase (non-routable) object. |
Revision-specific relationships are available to you only if the Agile administrator has configured Agile PLM to enable revision-specific relationship capabilities. Revision-specific relationships allow you to select a specific revision for a Part object, Document object, or Published Price object in a relationship
If Agile PLM has been configured for the use of reference objects, then you can add, on the Relationships tab, a reference, or link, to an object in an external application.
For more information about relationships, revision-specific relationships, reference objects, and how to use this tab, see the chapters about working with business objects in Getting Started with Agile PLM.
All objects have an Attachments tab. On the Attachments tab, you can attach files and URLs to the object by referencing those files and URLs in a file folder object. On the Attachments tab, you can view, copy (get), or print attached files if you have the appropriate privileges.
Individual attached files are stored in file folder objects and can be attached to multiple objects. The files in a file folder object can be drawings or scanned images, documents, non-viewable files, compressed files, and so on.
For detailed information about working with file folder objects and the Attachments tab, see Getting Started with Agile PLM.
|
Note: Files that pertain to an item should be referenced on the Attachments tab of the item, rather than the Attachments tab of a change that affects the item. |
For information about all change object tabs, see "Change Objects."
For information about working with Thumbnails, see Getting Started with Agile PLM.
The History tab shows a summary of actions taken against an object, including a description of the action, which user took the action, the date of the action, and other details.
|
Note: If you do not have the appropriate Read privilege for an object, then you cannot see the contents of the fields on the History tab. See "Details about Discovery and Read Privileges." |
The History tab shows a summary of actions taken against the change, including:
The current status of the change
The next status of the change
A description of the action
Which user took the action
The date and time of the action (local client time)
The user action time (optional, see "User Action Timestamp."
Which affected object was the subject of the action
The find number of the component of the affected item
Details of the action
Comments made by users
Users notified
While the change status is Unassigned or Pending, the following actions are recorded on the History tab:
The creation of the change.
Any subclass modifications.
Any actions on the Relationships tab and the Attachments tab.
Comments
Send
Subscribe
Save As
Share
Export
Delete
Undelete
|
Note: Actions for changes that have not moved out of the Pending status types are recorded for modifications to the Relationships tab and Attachments tab only. A change must have a status Type other than Pending, such as Submit or Review, before other actions are recorded on the History tab. |
The types of actions recorded after a change moves out of the Pending status are:
Modify or remove an item on the Affected Items tab
Redline an item on the redlines tab of the Affected Items tab
Add, get, check in, or check out a file attachment through the Attachments tab of the change
Add or remove reviewers
Approvals and rejections
Reminder notifications
Escalation notifications
Field change, any tab
Status change
Autopromotion failure
Attempt to change status without satisfying status-specific criteria
Subclass change
Comments
Send
Subscribe
Save As
Share
Export
Delete
Undelete
When you make modifications to a date field on a change after the change has exited the Pending status type, then Agile PLM records the dates and times in the Details column of the History tab using the local date and time on the computer where the Agile PLM Application Server is installed. Agile PLM uses a static format, for example, 2003/08/02 15:00:23 (GMT - 07:00) (yyyy/MM/dd) (Greenwich Mean Time).
Comments on the History tab are different from the comments on the Workflow tab. Comments on the Workflow tab come from approvers, acknowledgers, and observers when they perform the online approval process. Comments on the History tab can be made by anyone with sufficient privileges at any time.
For information about all change object tabs, see "Change Objects."
You can view Agile PLM changes that have been submitted to you in the Agile Workflow Routings Inbox.
To view the Workflow Routings Inbox in Web Client:
In the menu bar, click the Home button (or press Ctrl+Shift+H). Depending on the Preferred Inbox View setting in your user profile, either the Workflow Routings tab appears, or you can click Workflow Routings tab to display it.
To view the Workflow Routings Inbox in Java Client:
In the menu bar, click the small down arrow next to the Inbox button, and choose Workflow Routings.
See also: "Routing Managers: Change Analyst and Component Engineer."
For detailed information about working with routable objects, see Getting Started with Agile PLM.
Changes can affect site-specific information. Before you add affected items to a change, specify the manufacturing site that you want to affect. For general information about sites, see the chapter Chapter 3, "Sites and Distributed Manufacturing."
This section includes the following topics.
For information about working with the Affected Items tab, see the chapter Chapter 8, "Affected Items of Changes."
The following data is subject to change control:
Site-specific portion of the BOM
Site-specific portion of the AML
Dispositions
Effectivity dates
Release of a site association after the item is released
All of the above data can be directly edited before an item is released. After the item is released, BOM data and AML data may be redlined through an ECO, MCO, or SCO. A new item revision is not required, but will be made if the modification is made using an ECO.
See also: "Changes and Manufacturing Sites."
You can use an ECO to perform the following site-related actions:
Modify the common or site-specific BOM of an item.
Modify the common or site-specific AML of an item.
Modify dispositions site-specifically.
Modify the effectivity and obsolete dates of site-specific items.
See also: "Changes and Manufacturing Sites."
You can use an MCO to modify the common and site-specific AML of an item or change the lifecycle phase of an item.
You can use MCOs for all sites. In this example, there are two competing MCOs with site-specific information. When the first MCO is released, then the pending MCO is rebased to the newly released MCO. In a similar manner, if a pending MCO has competing site-specific redlines with a pending ECO or SCO, then when the ECO or SCO is released, the pending MCO is rebased to the newly released ECO or SCO.
See also: "Changes and Manufacturing Sites."
You can use site change orders (SCOs) to make site-specific changes to an item without changing the revision of the parent item.
With SCOs, you can modify the effectivity and obsolete dates, and the dispositions of previous revisions of an item, on a site-by-site basis. SCOs let you use an explicit process to propose, review, and approve the modification of effectivity dates and to record the reasons why the effectivity dates were changed.
|
Note: You cannot use an SCO to make redline modifications to a previous revision of an item. All redline modifications must be made to the latest released revision of an item. |
You can use an SCO to do the following:
Modify the site-specific BOM of an item for latest revisions.
Modify the site-specific AML of an item for the latest revisions.
Modify the site-specific dispositions. Includes latest and non-latest revisions.
Modify the effectivity and obsolete dates of site-specific items. Includes latest and non-latest revisions.
More than one site can be affected by an SCO, however, each row on the Affected Items tab applies to only one site. Duplicate items are not allowed. For example, if you add item P001 for site A, then you cannot also add P001 for site B. You cannot use an SCO to modify the common site portion of the BOM or AML. Also, you cannot use an SCO to modify the BOM of an item that has not been released by an ECO, that is, an SCO cannot modify preliminary BOMs.
See also: "Changes and Manufacturing Sites."
To modify or set the effective and obsolete date for a specific site, and nothing else is being done with the ECO, add the item to the Affected Items tab and create a new revision. If you do not want to create a new revision just for this modification, then create an SCO and modify the effective and obsolete dates for the site on the SCO Affected Items tab.
This section describes the rules Agile PLM uses to determine which revision of an item is affected by the change and offers additional guidelines. For more information about item revisions, see "Working with Item Revisions."
Items with an ECO Revision Only
A pending or released SCO can be based only on a revision created by a released ECO.
An ECO cannot be unreleased if there is a pending or released SCO based on it.
MCOs on Items with ECO Revisions
When a new ECO is created and released, and a pending MCO exists against a previous revision of the item, the MCO changes to be based on the new ECO revision, and it inherits content from the new revision.
An MCO cannot be unreleased if there is a released SCO based on it.
Items with an Initial MCO Revision Only
When an MCO is released against the item before the item is released by an ECO (called an initial MCO revision, or blank revision), a pending SCO cannot be based on the blank revision.
To create a change, you must have the appropriate privilege.
In Web Client, you can create an item with the Create New > Change command or the Actions > Save As command.
In Java Client, you can create a change with the File > New > Change command, the New Object button, or the Save As command, on the More Actions menu (click the More button at the top of the object window) and on the right-click shortcut menu.
|
Note: For a site change order (SCO), when you add an item to the Affected Items table, if the selected site is not listed on the Sites tab of the item, then you are prompted to add it to the Sites tab of the item. If you later cancel the SCO, or remove the item from the Affected Items table, then the new site assignment remains on the Sites tab of the item. |
For more information about creating changes and other objects, see Getting Started with Agile PLM.
|
Note: Once a change is created, it exists until you delete it. If you create a new change, and you then decide that you do not want to keep it, then be sure to delete the change (soft-delete, then hard-delete). Otherwise, the new change remains in the database, and the number cannot be reused. For information, see "Deleting Changes." |
See also: "Modifying Changes."
You cannot initiate Save As from a non-Site Change Order (SCO) change object to create an SCO object, nor can you initiate Save As from an SCO object to create a non-SCO change object. Because Site Change Orders (SCOs) affect only site-specific information, and other types of changes are not limited to site-specific information (for example, ECOs and MCOs), SCOs can be Save-As-created only from another SCO. The Site Change Order's site-specific only usage makes it incompatible with other change types when using the Save As feature.
With sufficient privileges, you can modify editable fields. You can modify only fields that have been made editable by the Agile administrator.
To edit a change:
On the Cover Page tab:
In Web Client, click Edit to put the Cover Page tab in edit mode. Modify the appropriate fields. Click Save when you are finished.
In Java Client, modify the appropriate fields. Click Save when you finish editing the Cover Page tab.
On the Affected Items tab, you can remove, add, and edit rows of affected items. (For more information, see "Adding an Item to the Affected Items Tab.")
On the Relationships tab, you can add, edit, or remove relationships, and you can add, edit, or remove relationship rules. (For more information, see Getting Started with Agile PLM.)
On the Attachments tab, you can add and remove references to files and URLs in file folder objects. (For more information, see Getting Started with Agile PLM.)
You cannot edit information on the Workflow or History tabs. Those tabs are completed automatically.
See also: "Creating Changes."
An Agile PLM workflow is a sequence of statuses that a change follows as it goes through the change control process. The Agile administrator specifies the name of the workflow, the number and names of the statuses, and the properties that define each status.
See also: "Routing Managers: Change Analyst and Component Engineer."
For more information about routing changes and other Agile PLM objects through workflows, see Getting Started with Agile PLM.
Redlining highlights, in red, changes made to an object. ECOs, MCOs, and SCOs are the only changes that have redlining functions. Use these changes when you need to modify a released item. For information about the functions of these types of changes, see "Change Classes."
This section contains the following topics:
Depending on your company policy, when you redline manufacturing data, use an ECO when you want to advance the revision of an item, or use an MCO when you do not want to advance the revision of an item.
For information about redlining a BOM, see "Redlining the BOM of a Released Item"
For information about redlining an AML, see "Modifying Manufacturing Data from the Redlines Tab"
For information about redlining attachments and Affected Files, see Getting Started with Agile PLM.
You can redline BOM and AML data and attachments using an ECO. In addition, you can create change-controlled redline modifications to item attributes.
ECOs let you release new items and modify previously released items. When you create an ECO, a pending item revision is created for any items modified by the change (the ones listed on the Affected Items tab). When the ECO is released, the pending item revision is converted to a released revision for each modified item.
See also: "What are Change Controlled Attributes?"
You can redline Design or File Folder files on the Affected Files tab of a Design File Change Order (DFCO). In addition, you can create change-controlled version-specific Title Block redline modifications.
DFCOs lets you publish new Design files and modify previously published files. You can add redline markup the affected files with the Agile AutoVue viewer, and you can add local files as redline markups. You can also use the Associate Redlines feature to consolidate Ad Hoc redlines, ECO redlines, and ECR redlines on the Redlines/Markup Files tab of the DFCO Affected Files tab.
For more information, see Getting Started with Agile PLM, chapter "Working with Design File Change Orders (DFCOs)."
See also: "What are Change Controlled Attributes?"
You can redline AML data using an MCO. In addition, you can create change-controlled redline modifications to item attributes.
MCOs are similar in appearance and function to an ECO. However, MCOs do not change the revision of an item, unlike an ECO. Instead, the MCO number is displayed alongside the corresponding revision number in the Rev drop-down list. For example, if there is a pending MCO #M12345 against Rev B of an item, then, on the Rev drop-down list, that revision is listed as (B) M12345.
MCOs can be used to:
Release a new item without a revision (but you can select its lifecycle phase)
Modify the lifecycle phase of an item without changing its revision
Redline manufacturing data (add, modify, or delete) on items (Manufacturers tab)
You can redline site-specific BOM data and site-specific AML data using an SCO, but only against the latest released revision.
SCOs are similar in appearance and function to an ECO. However, SCOs do not change the revision of an item, unlike an ECO. Instead, the SCO number is displayed alongside the corresponding revision number in the Rev drop-down list. For example, if there is a pending SCO S12345 against revision B of an item, then, on the Rev drop-down list, that revision is listed as (B) S12345.
|
Note: For detailed information about how to perform routing manager tasks, see the chapter "Routing Objects with Workflows" in Getting Started with Agile PLM. |
The user who oversees the routing and approval process of a change is the routing manager. The routing manager for changes is called the change analyst, and the routing manager for manufacturing change orders (MCOs) is called the component engineer. The Change Analyst or Component Engineer field on the Cover Page tab of the change lists the routing manager for that change. These fields are filled in automatically (as designated by the Agile administrator in the workflow settings) or selected manually by the user from a drop-down list.
Routing managers evaluate and assign changes, and they receive email notifications pertaining to the change objects to which they are assigned. Specific roles and privileges are required to perform the tasks of a routing manager. If you have questions about your assigned roles, contact the Agile administrator.
If the workflow specifies a Default Change Analyst, then the Change Analyst field is automatically populated by the workflow, even if you do not have Modify privilege for the Change Analyst field.
The following is an example of a typical change control process for a change using default Agile workflows:
A change (for example, an ECO or MCO) is created, and a workflow is selected.
The change is submitted to the change analyst (ECO) or component engineer (MCO).
The change analyst or component engineer switches the change to the next status, which routes the change to the specified approvers (members of the change control board) and observers.
The members of the change control board (CCB) either approve or reject the change, and their approval or rejection is recorded on the Workflow tab of the change.
If all the approvers approve the change and the acknowledgers acknowledge the change, then it is automatically promoted to the Released status (the next status).
|
Note: Agile Administrator settings, including workflow settings and SmartRule settings, control when a change can be autopromoted. These settings determine the required fields that must be completed, the required actions of the approvers and acknowledgers, and other conditions that must be met for autopromotion. |
If any approvers reject the change, then the change analyst or component engineer is notified and either:
Cancels the change by switching the status to Canceled.
Returns the change to the originator by switching the status to Pending.
Releases the change despite the rejection.
Depending on the workflow settings, the change may automatically be switched to a specified status when an approver rejects it.
For detailed information about working with and managing changes, see the chapter "Routing Objects with Workflows" in Getting Started with Agile PLM.
See also: "Agile Change Control Workflows"
See Appendix A, "Deleting Agile Objects" for important details about deleting change objects and about undeleting change objects.
You can print object tabs and other data from your Agile PLM system. You can print the current tab or all tabs. Attachments are printed from their native applications or from the AutoVue for Agile viewer.
In Web Client, with the object open, choose Actions > Print.
In Java Client, with the object open, use the Print button.
For additional information about printing objects, see Getting Started with Agile PLM.
When you print the Affected Items tab, redline information is also included.
