| 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 |
|
Note: For more information about the discovery warning messages, see the chapter about SmartRules in the Administrator Guide. |
The Agile administrator can use the Discovery privilege to limit discovery of objects in the following ways:
Prevent a set of users from seeing certain objects when they run a search. These objects are not displayed on the results table, even though they meet the search criteria. The Agile administrator can specify whether to display a warning message on the search results page.
Prevent a set of users from seeing certain objects that are listed on these tables:
Affected items
Where used
Manufacturers
Changes
Sites
User address book
The Agile administrator can specify whether to display a warning message.
Prevent a set of users from seeing certain objects on the BOM tab. The Agile administrator specifies whether to display a warning message. The Agile administrator also has the option of displaying either the item number only or the item description only on the BOM tab, so the user can see a complete BOM, but does not have access to the undiscovered items.
Prevent a set of users from running reports.
|
Note: While one set of users is prevented from seeing certain objects or fields, other users with different Discovery privilege and Read privilege settings can see those same objects and fields. |
To see the objects he creates, the creator of an object must also have the appropriate Discovery and Read privileges for the objects he creates. (See Administrator Guide, "Roles" chapter, Default Agile PLM Roles list for information about the Creator can read and discover object he or she created role.)
Discovery and Read privileges are assigned by the Agile administrator. If you have questions about your Discovery privileges or Read privileges, see the Agile administrator.
|
Note: The Agile administrator can create Read privilege masks that limit your ability to read specific fields. The Enforce Field Level Read privilege determines whether the Read privilege mask is enforced at the field level. If you have a role that includes the Enforce Field Level Read privilege, then you may not be able to view the contents of specific fields. This section describes how those non-viewable fields are displayed. For more information, see the Agile PLM Administrator Guide. |
If you do not have the appropriate Read privilege for a field, then the words No Privilege appear in the field.
If a copy of a non-readable field appears in another object or in a table, then the words No Privilege appear there also. For example, if you do not have Read privilege for the Description field of changes, then when those changes are listed in a table, the words No Privilege also appear in the Description field of that table. Following are examples of tables where objects may be listed:
Search results
Change history
Manufacturers
Where used
Affected items
Audit results
On the BOM table only, the SmartRule that determines how non-discovered items are displayed on the BOM table is also applied to the non-readable fields. See "How the Agile Administrator Controls What You See."
In general, if the document is shipped as part of a product, or it has costs associated with it, then create it as a part object. If the document is an internal document, procedure, or reference, then create it as a document object.
In certain cases, though, you may want to create a document as a part. Here are three examples illustrating when you might choose to create a document as a part object or as a document object.
Part or Document Example 1:
If a document is the controlling document for a part (that is, it has the same number as the part), then create that document as a part object.
For example, if you have an engineering drawing number 123 that specifies and describes part number 123 (thus the document controls the part), then create part 123 and include the engineering drawing as an attachment.
Use this method if the part number must be the same as the document number. When you use this method, the document does not exist as a separate document object in the Agile PLM database.
In contrast to the above example, if it is not necessary for the drawing number and part number to be the same, then create a document object (for example, document number 222) and add the engineering drawing to its Attachments tab (reference the engineering drawing in the appropriate file folder object). Then create a part object (for example, part 444). Add document 222 to the BOM tab of part 444 and enter zero or REF as the quantity. Enter zero as the find number. This forces a document object to appear at the top of the BOM tab for easy reference.
Part or Document Example 2:
If the document has costs associated with it, or it is shipped as part of a product, then create it as a part object.
An example of a document that is shipped with a product is a manual. A manual might have a BOM that includes the binder, labels for the binder, binder tabs, and the printed document itself.
If a document goes to your customer with a product, then create it as a part object, even if it does not have a BOM. Examples of such a document might be a warranty card, an instruction booklet, assembly instructions, or a printed software licensing agreement.
If the document has costs associated with it, such as printing costs, then create it as a part object. When you add the document part to a BOM tab, and you enter a quantity of 1, the costs of the document part object are included in any reports that compute costs. (See Getting Started with Agile PLM for information about running reports.)
Part or Document Example 3:
If the following applies to a document, then create it as a document object:
It does not need to have the same number as a part.
It is not shipped as part of a product.
It does not have costs associated with it.
Examples of such documents might be a manufacturing process (a Quality Assurance procedure, a test procedure, or manufacturing instructions) or a reference document (a specification or an engineering drawing).
Create any internal company documents as document objects.
|
Note: Because Agile PLM is so flexible, you are not required or forced to use the approach outlined in these examples when creating documents. You should, however, always follow your company's policies or guidelines when creating a document as a part object or as a document object. If you have questions, see the Agile administrator. |
If you create a document object, and later want to change it to a part object, then you can hard-delete the document object (if you have the appropriate privileges), which removes it from the database and frees up the item number. Then you can create the document as a part object, using the same item number. For more information, see Appendix A, "Deleting Agile Objects."
If the Agile administrator has created additional subclasses, and you have the appropriate privileges, then you can change the subclass of an item. For example, you can change the subclass of a particular document from Specification to Data Sheet.
|
Note: When you change the subclass of an item, its data fields change, and all previous information about the Page Three tab is cleared. |
To change the subclass of an item:
On the Title Block tab of the part, select a new subclass from the Part Type drop-down list.
If Page Three is visible and has data, then a warning message appears, alerting you that all Page Three data is cleared.
Web Client:
Choose Continue in the warning and click Finish to continue changing the subclass and to allow Page Three to be cleared.
Choose Cancel in the warning and click Finish to cancel the change subclass process. No changes are made to the item. In the object pane, click Cancel to discard your modifications and exit the edit mode.
Java Client:
Click Yes to continue changing the subclass and to allow Page Three to be cleared.
Click No to cancel the change subclass process. No changes are made to the item. In the object window, click Cancel to discard your modifications and exit the edit mode.
If the new subclass has an autonumber scheme assigned by the Agile administrator, then Agile PLM asks you whether to select a new autonumber for the new subclass.
Web Client:
Choose Continue in the warning and click Finish to continue changing the subclass and to allow the same number or name to be used.
Choose Cancel in the warning and click Finish to cancel the change subclass process. No changes are made to the item. In the object pane, click Cancel to discard your modifications and exit the edit mode.
Java Client:
Click Yes to change the subclass but retain the existing number.
Click No to reject the existing number. Manually select or enter a number, and then click Save in the object page or window.
If you reject the existing number in the Java Client step above, then you must manually select a new number. Depending on your system configuration, do one of the following:
If there is one autonumber source designated for the new subclass, then click the Autonumber button to assign a new autonumber. Click Save in the object window or page to complete the process.
If autonumbering is required in your system, and more than one autonumber source is designated for the new subclass, then use the Autonumber button to select one of the autonumber sources. Click Save in the object window or page to complete the process.
If an autonumber is not required, then you can type in a number. Click Save in the object window or page to complete the process.
|
Note: If the item is in use, then you may see a dialog alerting you that the item is locked. Click OK. The change subclass process is canceled. |
Agile PLM displays the new number in the Number field, and enters the event on the History tab of the item.
Agile PLM uses matching criteria to find which workflows may be used for each change. Agile PLM matches each change to a list of valid workflows for that change.
When modifying an Item, the server validates the workflow entry matching criteria of those Changes, PSRs or QCRs that have a workflow associated with them, and the workflow is not in the Completed or the Canceled status type.
The Agile administrator selects matching criteria from a list of reusable criteria. A reusable criteria is a database query, just like an advanced search. Reusable criteria are named and defined by the Agile administrator.
Some examples of possible reusable criteria are:
All MECOs - finds all the changes that are MECOs (mechanical ECOs).
Scorpio ECOs - finds all the ECOs that include "Scorpio" in the Product Line(s) field of the change.
Libra Project - finds all the change orders that have any items on the Affected Items tab that contain "Libra" in the Product Line(s) field of the item.
By specifying a list of reusable criteria for each workflow, the Agile administrator limits which changes can use a specific workflow. For example, the Agile administrator might create a workflow named General Use, and select the three reusable criteria named above (All MECOs, Scorpio ECOs, and Libra Project) as the matching criteria for that workflow.
Matching Criteria Example 1:
If you create a change that is a Mechanical ECO (MECO), then it matches one of the matching criteria of the General Use workflow (All MECOs). The General Use workflow appears in the Workflow drop-down list on the Cover Page tab of the change.
Matching Criteria Example 2:
If you create a change that is an ECO that includes "Scorpio" in the Product Line(s) field of the ECO, then it matches one of the matching criteria of the General Use workflow (Scorpio ECOs). The General Use workflow appears in the Workflow drop-down list on the Cover Page tab of the change.
Matching Criteria Example 3:
If you create a change order and add items to its Affected Items tab that contain "Libra" in the Product Line(s) field, then Agile PLM examines the Product Line(s) field on the Affected Items tab for every affected item. The General Use workflow appears in the Workflow drop-down list on the Cover Page tab of the change depending on the Criteria Matching Type setting for the workflow:
Some - One or more (but not all) affected items must match the affected item-based reusable criteria, in this case, Libra Project.
All - When multiple affected item-based reusable criteria are used as matching criteria, each affected item must match at least one affected item-based reusable criteria. However, each affected item does not have to match the same reusable criteria.
Same - All affected items must match the same affected item-based reusable criteria, in this case, Libra Project.
|
Note: As you add items to the Affected Items tab and complete the fields on the tabs of the change, the Workflow drop-down list on the Cover Page tab may vary, depending on which matching criteria apply at the moment. Contact the Agile administrator if you have questions about the matching criteria of a specific workflow. |
In Java Client, when editing a change object, click the Refresh button to save and update the change object and display the correct list of workflows in the Workflow drop-down list.
In Web Client, when editing the Cover Page tab, click the Validate button to save and update the change object and display the correct list of workflows in the Workflow drop-down list.
The Criteria Matching Type setting also applies for each status in the workflow. For detailed information about workflows and Criteria Matching Type, see the Administrator Guide.
Agile PLM calculates the revision number (or letter) that appears in the Rev field of the BOM table is by checking the release date of the parent item, if already released, and then locating the latest revision of the child item before that date and analyzing it. If the parent item has not been released, then the most recent revision of the child item is found.
The child item revision is analyzed according to three criteria:
Its lifecycle phase (Preliminary or other)
Whether there are any released revisions of the child item
Whether there are no released revisions of the child item
|
Note: In Agile PLM, if there are no released revisions of an item (the item has never been released), then the Introductory revision is considered the latest revision, regardless of whether there are pending revisions of the never-released item. See Appendix P, "Introductory Revisions." |
Depending on which revision of the parent you select, the child revision displayed may or may not be the latest revision of that child item. The following explains which child revision appears:
The latest revision of the parent item always displays the latest revision of the child item. That is, the parent BOM reflects any changes that may be made to the child item since the parent revision was released. This applies until the next revision of the parent is released.
The rev shown for a child item of any past revision of the parent item is the latest revision as of the time just preceding the next parent revision.
For each child item, the lifecycle phase appears that corresponds to the displayed revision.
The child item may display a blank Rev field if it has no revision number as of the release of the parent revision. This occurs:
If the child item has never been released as of the present moment, if you are viewing the latest parent revision, or
If it had not been released by the time of the next occurring parent revision, if you are viewing past parent item revisions.
|
Caution: Be aware that the unrelease and release of child items may affect the child revisions displayed on the parent BOM. |
|
Note: Pending revisions of the child item are not displayed on the parent item BOM table. However, any child item that has a pending change is indicated by the icon in its row in the parent item BOM table. |
The change order (ECO) or manufacturer change order (MCO) number associated with the displayed revision is included in the Item Rev column of the BOM table. The ECO number is the ECO that released the displayed revision. An MCO number is displayed with the revision upon which it is based.
Site change orders (SCO) are based on ECO-released revisions and the revision displayed on the BOM table may include SCO-defined content, however, SCO numbers are not displayed on the BOM table.
For more information about item revisions, see Appendix P, "Working with Item Revisions."
An orphaned item is an item that is not used in any BOM tree, therefore, the orphaned item does not have any parents. In the hierarchy of a BOM tree structure, there are parent items and children items. When an item no longer has any parents, then it is referred to as an orphan. On the Where Used tab of an orphaned item, the Where Used table is empty.
In an object search for item objects, in the search criteria attribute list, you can select the Where Used table Item Number text attribute as shown below. For this specific item search attribute, the search operators are limited to Is Null and Is Not Null.
Table 10-1 Orphaned item object search criteria
| Item object search criteria attribute | Description | Available Operators |
|---|---|---|
|
Where Used Item Number |
Specifies the latest released revision of the item object. |
Is Null Is Not Null |
|
Where Used Item Number All Revisions |
Specifies all the revisions of the item object. |
Is Null Is Not Null |
This orphaned item search attribute can be combined with other search attributes to define a narrow search for specific orphaned items. For example, the following search finds all parts without parents for the latest released revision where the product line is Gemini, and the specified date is later than May 1, 2013.
Item Number Is Null And
Product Lines(s) Equal To Gemini And
Page Two Date 01 Greater Than May 1, 2013
For more information about searching for objects in Agile PLM, see Getting Started with Agile PLM, chapter "Finding Agile Data with Searches".
You can generate quick access URLs that provide direct pointers to Agile objects, to Agile attachment files, or to Agile searches.
These quick access URLs can be pasted into other applications or files such as spreadsheet files, word processing files, a company Intranet web page or WIKI page, or into an email. When a user clicks the Smart URL, an Agile PLM Web Client window opens and displays the object, attachment file or search window.
Smart URLs can specify a specific tab, revision, or version to display when the object opens in Agile PLM.
For detailed information about all types of Smart URLs, see Getting Started with Agile PLM, chapter "Working with Business Objects in Web Client", section "Smart URL Quick Access to Objects, Files, and Searches."
